fix: use signature validity for receipt sealed report and commit / push allowed

[chtnnh]

Closes #2

Summary

Makes know-code status distinguish an attestation receipt’s signature validity from whether a commit or push is currently allowed. It also prevents a contradictory allowed: false response with no actionable blocker.

What changed

• Verifies gate.json against the local attest public key and exposes the result as receiptSealed in JSON.
• Uses that signature result for the human-readable receipt ... sealed= field, instead of reusing the broader authorization decision.
• When runCheck denies an otherwise complete pipeline (for example, because the pending commit message lacks Know-Code-Verified), adds its reason and command as the status blocker and next step.

Why

A valid receipt can coexist with a temporarily closed commit/push gate: after a pass, the next commit still needs a grounded trailer. Status now reports both facts accurately and directs the user to know-code commit -m "…" rather than implying that the receipt itself is unsealed.

Coverage and verification

• Adds a regression covering a signed, fully satisfied receipt that is denied only for a missing pending trailer; it asserts receiptSealed: true, the check-level blocker, and the commit command.
• npm run lint
• npm run build
• npm test
• Two consecutive independent GPT-5.6 Sol xhigh correctness reviews: clean.

[cursor]

PR Summary

Low Risk
CLI status reporting and blocker UX only; no changes to enforcement or attestation verification semantics beyond clearer output.

Overview
know-code status now reports whether the gate receipt is cryptographically sealed independently of whether commit/push is currently allowed, and surfaces actionable blockers when the pipeline looks complete but runCheck still denies.

JSON output adds receiptSealed (attest signature verification on gate.json). The CLI receipt … sealed= line uses that flag instead of tying “sealed” to allowed, so a valid signed receipt can show as sealed even when the gate is closed (e.g. requireTrailer pending on the next commit).

When allowed is false, the pipeline has no blockers, and runCheck supplies a reason, status merges a check blocker and sets nextStep from check.next—fixing empty blocker lists in cases like a missing Know-Code-Verified trailer.

A regression test builds a fully signed pipeline state denied only for the trailer and asserts receiptSealed: true, the check blocker, and know-code commit -m "…" as next step.

^{Reviewed by Cursor Bugbot for commit e6b7a82. Bugbot is set up for automated code reviews on this repo. Configure here.}