fight: close the green-polarity gap — classify gates that could not run (escalate only)

[hyperpolymath]

squabble fight classifies red checks as self-win | escalate | assign-owner. A gate that could
not run reports green, so the engine never looks at it. That is the entire fake-green class: a
scanner goes missing, a stub writes [], the check goes green, and the gate silently stops being a
gate.

Directive: .machine_readable/bot_directives/gate_triage.a2ml (added in #57).

The detection needs no workflow change

The unavailability marker already exists in the Actions jobs API. A vacuous run reads:

Run <scanner> scan     conclusion = skipped
Create stub findings   conclusion = success
check conclusion       = success

That step-conclusion pair is the machine-readable "I could not run" report. Nothing needs to be
added to any workflow to emit it.

Scope

1. Extend the run inspector to fetch step conclusions for checks that concluded success, not only
   for reds.
2. Match the stub signature. Where it matches, classify.
3. Emit escalate only, carrying evidence: run-count, stub-rate, upstream-exists,
   target-tech-present.
4. Check Axis 0 first: a gate skipped because its declared @gitforge_OperatorType or @channel
   does not match is correctly inapplicable by declaration — report not-applicable, do not
   escalate it. Declarations live in 0.1-AI-MANIFEST.a2ml.

Two hard constraints

Do not break the SPARK proof. spark/ proves the only transition into Green is a required check
that actually ran and passed. Unavailability must classify as escalate, never self-win.
escalate is an existing terminal non-green state, so a classifier that only ever emits it leaves the
proof untouched. Go/no-go: if the change stays inside escalate, implement it; if it needs a new
state, write a spec first and stop. Deletion of a worthless gate is a recommendation to the owner,
never an enacted transition.

Standalone. gitbot-fleet/robot-repo-automaton takes precedence wherever it is present and
working; this repo is the backup for people who adopt a squabbler per repo and nothing else. ANCHOR
already declares hypatia-dependent as an IS-NOT — the signature match must be scanner-agnostic,
keyed off the directive's signature-skipped-steps / signature-success-steps lists rather than
hardcoding Hypatia.

Why now

The Hypatia gate was measured on 2026-09-03 to have four independent routes to a fake-clean
result, and had been green-and-meaningless across ~91 repos. Every one of those greens would have
been caught by this check on its first run.

[hyperpolymath]

Queued by PR #60.

#60 hits the go/no-go here exactly: a fully-green gate has no typed home for a
vacuity finding, because Outcome::Green carries no Report. Adding one would
change an outcome state, so per this issue's rule ("if it needs a new state,
write a spec first and stop") #60 does not add it — that path reports on
stderr instead, visible in both human and --json modes, with the limitation
named in the message.

So the spec-first work this issue asks for is now concretely motivated by a
shipped limitation rather than hypothetical. The shape needed:

• where a finding attaches when the gate is green (a Report on Green, a new
  outcome, or a separate reporting channel);
• whether a green-but-vacuous gate should change squabble fight's exit code
  (it currently does not — deliberately, since that would make a reporting
  change behave like a gate change);
• how it interacts with the SPARK invariant, which today models only
  Missing/Pending/Failed/Passed and is untouched by feat: classify green checks that never actually ran #60.