TileGenerator stores scale factor of tiles (in relation to original s…

[gentledepp]

Summary

• TileGenerator.WriteMetadataAsync now also writes scaleX and scaleY (in addition to width/height) into dimensions.json.
• For the SVG overload, the factor is pyramidW / docSize.Width (and Y analogous) — i.e. how much larger the rendered tile pyramid is than the original SVG document.
• For the raster overload (JPG/PNG source), scaleX = scaleY = 1 is written, since the plan coordinate system equals the source pixel grid.
• Values are serialised with "R" round-trip formatting against CultureInfo.InvariantCulture so locales with comma decimal separators don't corrupt the JSON.

Why

Consumers of the tile archive (in iCl.Filler.Avalonia) need this factor to re-map PlanItem coordinates between the original SVG coordinate system (in which they are persisted in production) and the higher-resolution tile pyramid. Without these fields the consumer cannot align pins/polygons on tile-rendered plans.

Test plan

• New test GenerateTilesFromSvgAsync_WritesScaleFactorsToDimensionsJson verifies that with targetWidth = 10 × docSize.Width, scaleX ≈ 10 and scaleY ≈ pyramidH/docSize.Height are written and round-trip through JsonDocument.
• Extended GenerateTilesFromSvgAsync_ProducesExpectedZoomLevels to also assert scaleX/scaleY are present.
• Red/green: removed the new fields from WriteMetadataAsync, confirmed test fails; restored, confirmed it passes.

Compatibility

Older tile archives without scaleX/scaleY will fail the strict parse on the consumer side and fall back to SVG/image rendering as before — no regression. The consuming feature is still in development, so backward compatibility of existing pyramids was not a requirement.