status: 'receipt sealed=' reports check-allowed, not signature validity (and 'allowed: no' can print with no blockers)

[chtnnh]

Found during 0.3.0 release-day dogfooding (2026-08-11), cost real human time mid-flow.

What happened: right after a successful human pass, know-code status printed:

• commit/push allowed: no with no blockers list
• receipt: standard @ … sealed=no for a gate that was correctly Ed25519-signed

Root causes:

1. status.ts prints sealed=${allowed ? "yes" : "no"} for the receipt line — it renders the overall runCheck result, not the receipt's signature validity. A perfectly sealed gate shows sealed=no whenever the trailer check denies.
2. The deny came from requireTrailer evaluating a stale .git/COMMIT_EDITMSG (left over from a soft-reset commit, carrying a superseded trailer). That state is expected between pass and the first know-code commit (which pre-writes a grounded EDITMSG), so status should either explain it or not count it as a blocker.
3. allowed: no with an empty blockers section is contradictory output; if check denies, status must show why.

Fix directions:

• receipt … sealed= should reflect assertSigned on gate.json only.
• Surface the trailer-deny reason in the blockers list, with a hint when the pending EDITMSG trailer is stale but the gate is open ("next: know-code commit stamps a fresh trailer").