feat: Add dot width correction for raster engraving

[vyvcodd]

Summary

Adds LightBurn-style "Dot Correction" support to raster engraving: shortens the marked area of every continuous engraved run by compensating for the physical width of the laser spot, so engraved images come out at their intended size instead of slightly larger/darker along the scan-line direction. This especially matters for fine detail — thin dark features and the gaps between them are closest in size to the spot diameter, so without correction they're the first to over-thicken and wash out.

Depends on the raygeo change in branch feature/dot-width-correction (https://github.com/vyvcodd/raygeo/tree/feature/dot-width-correction), which does the actual work: it delays laser-on and advances laser-off by half the spot diameter at each end of every engraved run, without changing any toolpath geometry. See that branch's PR description for the full rationale — in short, this is a firing-timing correction, not a geometric one, so it's implemented separately from (and cannot reuse) the existing kerf/tool-radius offset machinery. It also documents a known, deliberate limitation: engraved detail smaller than roughly the spot diameter is dropped entirely rather than shrunk to a point, since this feature is inherently a lossy scale-down of the burn and a hard threshold is the easiest version of that tradeoff to reason about.

Changes

• EngraveStep.dot_width_correction_mm (raster_step.py): Optional[float], defaulting to None (auto = half the selected laser's spot_size_mm[0]), same convention as the existing line_interval_mm/sample_interval_mm — auto value shown as the default, explicit override once the user edits it, no separate toggle. Wired through get_assembler_kwargs/assemble_on_surface into the new dot_width_correction_mm kwarg on the raygeo raster() assembler.
• raster_widget.py: new "Dot Width Correction" Adw.SpinRow in RasterSettingsWidget, next to Line Spacing / Sample Interval.
• test_raster_step.py: updated test_get_assembler_kwargs's expected key set, added a roundtrip-serialization assertion for the new field, and a mocked assemble_on_surface test (TestAssembleOnSurfaceAutoDefaults) asserting the auto-default actually resolves to half the laser's spot size at generation time, and that an explicit override is respected — this exact "resolves to the right value when generating, not just a hardcoded placeholder" class of bug is what the settings-widget-auto-value-bugs PR fixed for the other raster fields, so it's worth locking down here too.

Checks

• rayforge/builtin_addons/rayforge-addon-laser/tests/steps/test_raster_step.py: 8 passed.
• Full suite (tests/ + rayforge/builtin_addons/), rebased onto current main: 5277 passed, 300 deselected.
• Not yet manually verified in a running app — the automated screenshot check (scripts/screenshot/cli.py step-settings:engrave:general:variable) hung in this environment and was killed rather than left running; worth a quick manual look at the new spin row before merging.

Sequencing note — do not merge before the raygeo pin bump

This is not a dormant feature waiting on a later release — it's a breaking change against the currently-pinned raygeo. dot_width_correction_mm is passed unconditionally on every raster generation, and the pinned release (1.23.0) doesn't accept that kwarg at all:

raster() got an unexpected keyword argument 'dot_width_correction_mm'

Verified directly against the actual cached 1.23.0 wheel. Every Engrave step would fail to generate. This must land in the same PR (or immediately after, with no gap) as the raygeo pin bump to the release that includes feature/dot-width-correction, matching the existing "bump pin + migrate code" convention already used for every other raygeo version bump in this repo's history. Until then, test locally with scripts/run_with_local_raygeo.sh ../raygeo pointed at that branch.

[knipknap]

Raygeo 1.24.0 is now pushed!

[vyvcodd]

I've updated the Raygeo version

FYI the default Dot width is configured laser width/2, lightburn has a toggle button and value, I've just left it as a value. What do you think?

[knipknap]

Sweet, looking good! Thanks for the PR!

I will push a small change thereafter to also support this in the existing Lightburn import.