[knipknap]

Fixes two problems from the #613 follow-up (see the latest screenshot
there: after zeroing the WCS at an object, right/top jog buttons are
blocked, and the green marker cannot be seen).

What does this PR change?

1. The work origin marker was invisible. It drew its axis lines
   with a world-unit stroke width of 0.2 mm - thinner than a pixel at
   most zoom levels, so anti-aliasing washed the green out entirely
   (pixel analysis of the Workarea rendering is displaced when "Workarea Origin Is Coordinate Zero" is disabled with negative machine coordinates (GRBL) #613 screenshot finds only a faint tint
   along the gridlines at the zero position; the marker also sat at
   the bottom of the element stack, under the extent frame, workarea
   fill, and workpieces). It now strokes with a device-space hairline
   (same technique as the extent frame) and is raised above the work
   geometry, keeping only the position dots above it.

2. Jogging was blocked after zeroing the WCS mid-bed. The soft
   limit check shifted the machine position by the active WCS offset
   before comparing it against the limits - but the limits are a
   machine-space box (extents with reversal applied; configured
   values flipped from origin-corner distances). With the work origin
   zeroed at an object (G54 -292/-341), the work position sits in
   0..400 while the box is [-400, 0], so every right/top jog was
   clamped to zero, while left/down jogs were allowed to run to work
   -397 = machine -689, a guaranteed firmware soft-limit alarm. The
   clamp now compares the machine position against the machine-space
   box, so the limits hold at the physical bed edges regardless of
   where the work origin is zeroed.

Why did you choose this specific architectural approach?

The bed-space evaluation supersedes the work-space evaluation
introduced in #577 (issue #574). That setup paired a bottom-left
origin with firmware reporting negative machine positions and a G54
used as a UI correction - precisely the misconfiguration diagnosed in
#613: the machine was not configured to match its firmware. With the
machine configured correctly (origin corner = firmware zero corner,
reversal flags matching the sign convention, G54 at zero), the
displayed coordinates are the machine-native ones, the limits describe
the physical bed, and machine-space evaluation is correct in every
zeroing workflow - mid-bed re-zeroing included. The #574 regression
tests are rewritten to that corrected configuration, and the
hardware docs no longer claim that limits follow the work origin.
Deliberately unchanged: the Z travel check (already machine-space).

How did you manually test this locally?

1. pixi run lint; pixi run test tests/machine/ tests/ui_gtk/canvas2d/ (2562 passed).
2. New unit tests: the marker deposits a clearly green stroke at
   1x/2x/6x zoom (the old 0.2 mm width fails at low zoom); clamping
   with a mid-bed WCS zero allows right/top jogs, clamps at the bed
   edges for default and configured limits, and the orange warning
   ignores the WCS offset. The Jog buttons stay orange – can only jog right and back, left/forward blocked even far inside work area #574 regression tests are rewritten to
   the corrected configuration as described above.
3. Headless (Xvfb) run with the Workarea rendering is displaced when "Workarea Origin Is Coordinate Zero" is disabled with negative machine coordinates (GRBL) #613 machine configuration and
   G54 -292/-341/-3: the marker renders as a clearly visible green
   origin symbol at the zero position (previously zero green pixels
   in the canvas).

Checklist

• I am not an AI. I have manually read the code and understand it.
• I take full responsibility for the quality and architectural fit of
  this code.
• I agree to publish this code under the MIT license.

Prepared with agent assistance at the maintainer's request; please
review before checking the boxes.

[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
0f27be5a	fix(canvas): make the WCS marker visible and clamp jogs against the bed	158 / 68	2,260	$0.0339
Total		226	2,260	$0.0339

Added lines by language: Python 125, Markdown 33

Full estimate

Component	Est. tokens	Est. cost
Code emission (226 add/rewrite lines)	2,260	$0.0339
Context input (reading touched files)	28,578	$0.0857
Conversation replay (≈15× output)	33,900	$0.1017
Prompting (pull request description)	732	$0.0022
Lower bound (output only)	2,260	$0.0339
Best estimate	65,470	$0.2235

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.