feat: position workpieces relative to a chosen origin

[knipknap]

Summary

Workpieces can now choose which local point their X/Y position refers to and which point stays fixed when they are resized or regenerated:

• Corner — the lower-left corner of the bounding box (previous X/Y semantics, now also the regeneration anchor)
• Center — the box center (the previous regeneration behavior)
• Reference point — the geometry provider's logical origin; sketches report their fixed origin

The properties panel gains a Position relative to selector for single workpieces, and the X/Y rows then show and set the chosen point's position — so X=0/Y=0 places the sketch origin at the machine/WCS origin.

Motivation

Parametric sketches previously drifted whenever their parameters changed: geometry was normalized to the bounding box corner, and regeneration preserved the box center. With both cut- and engrave sketches constrained around the sketch origin and positioned via the reference point, they stay registered to each other across any parameter change.

Details

• IGeometryProvider gains get_reference_point() (default None); Sketch reports its fixed origin point.
• WorkPiece.anchor_mode (serialized) selects the anchor; regeneration resizes around the anchor and re-positions so it stays at its world position. Both regeneration paths honor it: parameter overrides (regenerate_from_geometry_provider) and sketch edits (UpdateAssetCommand).
• DocItem.set_size() accepts an anchor parameter (local point to keep in place); the anchor lifecycle itself stays in WorkPiece.
• The screenshotter gains a main:item-properties target (properties panel only, no full window), and the positioning docs embed the new screenshot in all languages.

Note for addon authors: providers must now implement get_reference_point(). The protocol default returns None, so providers inheriting IGeometryProvider need no change — but structural (duck-typed) implementations must add the method to keep passing the runtime isinstance checks.

Testing

• New unit tests: anchor mapping, set_size anchor preservation, serialization round-trip, and regeneration keeping corner/center/reference fixed (including the asymmetric-bbox case).
• New regression test: finishing a sketch edit (UpdateAssetCommand) keeps the reference anchor fixed.
• pixi run lint clean; targeted suites pass (tests/core, tests/doceditor, sketcher and laser step tests).

[github-actions]

🤖 Estimated LLM implementation cost

Replayed each of the 1 commits in this pull request and counted the code lines each commit added or rewrote:

Commit	Message	Lines (add/rewrite)	Est. output tokens	Est. output cost
3472d604	feat: position workpieces relative to a chosen origin	828 / 79	9,070	$0.1361
Total		907	9,070	$0.1361

Added lines by language: Python 547, Markdown 281

Full estimate

Component	Est. tokens	Est. cost
Code emission (907 add/rewrite lines)	9,070	$0.1361
Context input (reading touched files)	83,309	$0.2499
Conversation replay (≈15× output)	136,050	$0.4082
Prompting (pull request description)	429	$0.0013
Lower bound (output only)	9,070	$0.1361
Best estimate	228,858	$0.7954

Cost model: ≈10 tokens per code line at $15/Mtok output and $3/Mtok input (assuming heavy prompt caching); input ≈ 15× output for conversation replay; a review round ≈ 42,000 tokens; a failed CI run ≈ 21,000 tokens; file reads capped at 20 kB each.

Active window from first commit to merge: <1 day.

⚠️ Caveat: the lower bound covers only the tokens for emitting the code. The best estimate adds modeled overhead for exploration, conversation replay, review and debug turns, but real sessions vary by tool and task — treat it as an order-of-magnitude figure. Human engineering time is not included.