Finish the x32 xy_microsteps default in the baseline test and the stream harness

The x32 default landed in forgetest/baseline.py and the driver, but two
callers still judged the machine at x8 and both failed on the host.

forgetest/tests/test_baseline.py: setUp seeded the fake machine from the x8
FIXED_SYSFS literals while enforce() compares against fixed_sysfs() of the
resolved mode, so x_mode, y_mode, step_freq and ramp_rate read as deviations
on a clean machine - 23 failures across BaselineTests and
TransientNotLeftoverTests. It seeds from fixed_sysfs() now, and the tick
expectations come from it (DEFAULT_TICK) rather than a typed 28160. The
xy_mode_of and ref_xy_mode unset/invalid cases expect 32, with an explicit
"8" case added that had no coverage. Two reference_preconfig dumps taken on
an x8 machine carry xy_microsteps = 8, because the markers are read at the
reference's own mode. wait_configured wrote the static CONFIGURED_MARKERS
where the function watches configured_markers() of the mode in force, and
the held-controller jog typed 221 steps for "4.144 mm", which is 1.036 mm at
x32; both derive from the mode now. 69 tests, all pass.

scripts/bench/laser_stream_test.py: STEPS_PER_MM was the x8 53.333, so the
X-peak check failed at 2133 steps against an expected 533. The whole harness
now derives from XY_MICROSTEPS_BASE/DEFAULT the way glowforge.h and
baseline.py do, which uncovered five more x8-only expectations behind the
first: the machine tick, the fire-gap limit (it grows as sqrt(k), not k - a
finer mode shortens the accel interval by sqrt(k) while speeding the tick by
k), the rung split in fire_spans, the density period and minimum burst
(laser_pulse_ticks is in x8 ticks and the stream scales it, so the config
keeps the x8 numbers and the measured lengths scale), and the decel/hold
budgets. Run against the null-sink build: all stream emission rules hold.

xy_mode_test.py's docstring still described the no-key case as x8 while its
own assertions had moved to x32.

No behavior change and no acceptance-catalog consequence: these are test
expectations and a bench harness, not image component sources. The coverage
lint is unchanged at 0 uncovered paths.

scripts/bench/xy_mode_test.py

@@ -11,12 +11,12 @@ never takes them typed: $100/$101, the machine tick, and the kernel stop
 ramp. This harness drives the native grblHAL_glowforge binary in
 null-sink mode (no hardware, no root) over TCP, one process per config:
 
-  1. no key: x8, $100/$101 = 53.333, the 28160 Hz tick
+  1. no key: x32, $100/$101 = 213.333, the 112640 Hz tick
   2. xy_microsteps = 16: 106.667, the 56320 Hz tick; a typed $100 is
      overwritten on the spot; $110 is left alone under a tick that
      carries it
   3. xy_microsteps = 32: 213.333, the 112640 Hz tick
-  4. a value that is not a mode: x8 with a warning in the log
+  4. a value that is not a mode: x32 with a warning in the log
   5. GFSINK_RATE lowered under the mode's tick: $110/$111 are held at
      the feed the tick carries, one step per tick per axis