Preserve full-sweep HATCH boundary angles

[mediummandoo]

Description

HATCH arc and ellipse boundary angles were normalized independently while being converted from radians to degrees. A full sweep such as -π/2 to 3π/2 was consequently written as 270 to 270, collapsing the boundary.

This change converts those four boundary values without normalizing either endpoint. Other DXF angle writers are unchanged.

Tasks done in this PR

• Preserve full-sweep arc and ellipse boundary angles.
• Add a synthetic write/read regression test for both edge types.

Related Issues / Pull Requests

• None.

Notes for reviewer

• DXF reference: HATCH boundary path data
• The conversion is kept local to HATCH boundaries to avoid changing angle normalization elsewhere.
• Test: dotnet test ACadSharp.Tests/ACadSharp.Tests.csproj --framework net9.0 --filter FullyQualifiedName~DxfHatchWriterTests

[DomCR]

The methods that you are replacing do the same as the change, it seems a redundant change.

[mediummandoo]

Thanks for reviewing. I checked the exact CSUtilities revision pinned by ACadSharp (fdf1403ede6e3376a0baa1deac166cbe4d21262e). MathHelper.RadToDeg is not equivalent to direct multiplication: it always calls NormalizeAngle(result), and its absolute parameter is currently unused.

For this full sweep:

• RadToDeg(-π/2) produces 270
• RadToDeg(3π/2) also produces 270
• direct conversion produces -90 and 270, preserving the 360-degree span

The DXF reader only converts those values back with DegToRad, so it cannot recover the lost sweep. This is the case covered by the added arc and ellipse regression test.

Would you consider reopening this PR? If you prefer, I can instead fix the unused absolute behavior in CSUtilities and update ACadSharp to use RadToDeg(value, false).

[DomCR]

I see, the issue then is in CSUtilities, it should allow the option for non absolute values in range of -360 to 360, reopening the PR.