cloud.pause-resume reads the job's limits through; pin the pass-through

The pulse header's envelope now reaches the cooling engine: the cloud
client (python3-gfhardware c34faa1) derives the coolant window and the
fans' minimum speeds from the header and rides them on every report,
and the engine (forgectrl 57f6064) resolves each as the stricter of its
setting and the job's, never looser and never overruling an off gate.
cloud.pause-resume, which runs a real print, now also reads the client's
"job limits from the header:" line and the engine's "effective limits:"
line from the two logs; two host cases cover the failure paths. The
needle guard lists the engine's phrases as not the app's.

COOLING.md section 2 explains what a cloud job brings with it; BRINGUP
item 19 records the pass-through as landed. Pins: forgectrl 57f6064,
forgefirm-app c34faa1 (0.1.14+git); fetch-verified.

docs/BRINGUP.md

@@ -1325,8 +1325,16 @@ Open items only. Anything closed is in `CAMPAIGN-LOG.md`.
     flow window and the flow rise (`forgectrl/src/gates.c`, `SERVICES.md`
     "Gate settings", `COOLING.md` §8a, `cooling.gate-off` in the catalog,
     bench PASS 2026-08-21 on dev image `20260821210903`).
-    The fan gates, the pass-through of header limits, the coolant critical
-    tier and the watch-only board temperatures follow on it.
+    **The pass-through is in:** the cloud client derives the job's limits
+    from the header (`CMrx`/`CMrn` as degrees, `EFrx`/`IFrx`/`AArx` as the
+    minimum speeds their maximum periods mean) and rides them on every
+    `/cool/state`; the engine resolves each as the stricter of local and
+    header, never loosening and never overruling an off gate, logs the
+    effective set and publishes it in `/cool/status`; the coolant ceiling
+    is the live consumer, the floors wait for the fan gates
+    (`cloud.pause-resume` checks both log lines on a real print). The fan
+    gates, the coolant critical tier and the watch-only board temperatures
+    follow.
 
     Nothing here can put energy where it was not commanded: the hardware chain
     is the emission boundary and no header field touches it, and forgectrl runs

docs/COOLING.md

@@ -76,6 +76,19 @@ a program is playing, the engine additionally stops motion and locks the laser
 latch itself. It also refuses to let exhaust and intake drop below cooldown
 duty while a program is still running.
 
+**A cloud job brings its own envelope.** The pulse file the Glowforge service
+sends opens with the job's operating limits, and the cloud client hands the
+ones the engine has a use for along with every report: the coolant window
+and the fans' minimum speeds. The engine takes each only where it is
+stricter than the setting on the Machine tab: a ceiling can only come down
+for a job, a floor can only go up, a looser value is noted in the log and
+ignored, and a gate you turned off (§8a) stays off whatever the job says.
+The coolant ceiling is the one limit a job can tighten today (the service
+sends 33 °C on a cut, which is also the shipped default); the fan floors
+are carried and logged ahead of the airflow gates. The effective set shows
+in the log as `effective limits:` and in `/cool/status` as `limits`. A GRBL
+job has no header and runs on the settings alone.
+
 **If a diagnostic takes the hardware over** (§6), the engine suspends its own
 writes and publishes fire-blocked until the diagnostic finishes.