cooling.gate-off: a gate setting trips in range and is off at its far end

The acceptance catalog gains the test behind forgectrl 9e44fdc: the
coolant ceiling set just over its legal minimum must trip OVERTEMP with
a hold and fire blocked at the next run start; set to its top the engine
must skip the gate (verdict OK), report it in gates_off on /status and
/cool/status, and log the run-start line; the original values are
restored, on failure too, and proven restored. Five host cases against a
scripted engine. The cooling covers map now names the files that carry
gate state (gates, settings, status, the panel) and corrects a glob that
matched nothing: the GRBL cooling client is src/glowforge_cooling.c, not
src/gfcool*. The fake forgectrl serves /logs/tail and keeps blank form
values as "clear", which is what the daemon does with them.

Docs: COOLING.md section 8 carries each setting's legal range and
recommended band and a new 8a on turning a gate off; SAFETY.md names
what no setting can reach; ACCEPTANCE.md records that gates are
exercised through the settings API, never GFCOOL_* env overrides;
BRINGUP item 19 records the pattern as landed and the catalog is 43.

forgectrl pin moves to 9e44fdc; fetch-verified.

docs/ACCEPTANCE.md

@@ -235,6 +235,11 @@ tests:
 2. does that test's `covers` map name the files touched - if not, widen it
    in the same change.
 
+A gate or a limit is exercised through the settings API (a value a healthy
+machine cannot meet, re-read by the engine at the next run start, restored
+by the test's own teardown), never through `GFCOOL_*` environment overrides,
+which need a daemon restart and stay bench-only.
+
 A behavior change with no catalog consequence needs a sentence of
 justification in the commit message. Coverage gaps are defects: under the
 domain model an uncovered path lets an inherited PASS stay valid across a