Homing is lid-gated in practice; only the cloud hunt is not

MOTION said jogs, homing and hunts were all ungated. Jogs are:
gfsw_visible withholds the door signal while the core is idle, jogging or
homing, so a jog both starts and runs with the lid open. Homing is not.
With homing_mode = gfcloud - the only method that works today - $H hands
the cycle to a cloud homing session, and its move to the home corner is
an ordinary motion action taking the default lid_gated=True: refused with
the lid open, stopped on a lid edge mid-run. Only the lens/Z hunt inside
that session passes lid_gated=False, and that session is also the only
place a hunt happens in GRBL mode - there is no hunt outside one.

BRINGUP gains item 18: GRBL pause and resume should leave no gap in the
cut, the way the factory's does. The beam stops at the start of the hold
(disable_laser_during_hold, on by default), so the head travels the whole
deceleration dark and the resume restarts from a standstill where the
decel ended - an unburned length, then a dwell through the accel that M3
shows as a deeper spot. The kernel waypoint backtrack cloud mode uses is
refused with EPERM on a live-streamed ring, so the equivalent has to be
built above the ring, where grblHAL still holds the planned path the
kernel has already overwritten.

Two wording fixes: the cooling verdict is described as a report rather
than a file, and gfcloud homing as using the machine's builtin
credentials.

Documentation only - no behavior change, so no acceptance-catalog
consequence.

docs/MOTION.md

@@ -293,8 +293,18 @@ ForgeFIRM reproduces the factory machine's behavior:
 - **Idle lid cycles are ignored.** Opening the lid to load material, or
   powering up with it open, does not leave the controller parked — senders
   connect normally.
-- Jogs, homing and hunts are not lid-gated (the beam is blocked in hardware
-  regardless).
+- **Jogs are not lid-gated.** The core is blind to the door signal while it is
+  idle, jogging or homing, so a jog both starts and runs with the lid open —
+  the beam is blocked in hardware regardless.
+- **Homing is lid-gated in practice**, even though the core does not see the
+  door during `$H`. With `homing_mode = gfcloud` — the only method that works
+  today — the cycle is a cloud homing session (§5.7), and its move to the home
+  corner is an ordinary motion action: refused with the lid open, and stopped
+  if the lid opens partway through. The camera steps need the lid closed
+  anyway. Only the lens/Z **hunt** inside that session ignores the lid (§6.3),
+  which is where hunts happen in GRBL mode — there is no hunt outside a cloud
+  homing session. Under `homing_mode = switches` a Z reference would just be
+  part of the core homing cycle.
 
 The next job re-arms with a fresh button press — the same press the hardware
 button latch itself requires, which is why software and hardware cannot
@@ -310,8 +320,8 @@ The homing method is a setting (`homing_mode`), chosen in the web panel:
 
 - **`gfcloud`** — camera homing through the Glowforge web service, the same
   cycle the factory machine runs. `$H` suspends the stream engine, runs the
-  session, then hands the machine back. Takes roughly a minute and needs a
-  signed-in Glowforge account.
+  session, then hands the machine back. Takes roughly a minute and uses the
+  machine's builtin credentials.
 - **`switches`** — the future limit-switch cycle. Not enabled yet; brackets for
   the switches are in the project's `3d-models/` directory.
 - **`none`** — `$H` is rejected.