Integration: rules as part of the signed schema artifact (audit/compliance)

[rrrodzilla]

Workstream: Integration · Part of #89

Context

A key compliance win: a declarative rule is part of the signed schema artifact — reviewable in a PR, covered by the signature, an auditable control for ATO — unlike opaque out-of-band hook binaries. Must integrate with the existing signing pipeline (sign/verify, off→warn→enforce, trust bundles).

Scope

• Ensure rule definitions are inside the signed schema payload and covered by signature verification.
• Confirm verify and the enforce stage reject tampered rules.
• Document the audit story (how a reviewer enumerates all rules gating an entity).

Acceptance

• Rules are signed/verified with the schema; tampering fails verification; audit doc added.

---

Dependencies: Suggested order: after rules persist in the schema payload (#103). Soft.

[rrrodzilla]

Landed in 5b845f0 — test(signing): prove tampering a signed rule annotation is rejected (#106).

Verified: schema-forge-signing/src/policy.rs::verify_one_file hashes the raw .schema file bytes (sha256), checks against the manifest's pinned hash, and verifies the signature over those bytes. Since @require/@compute/@default are annotation text inside the file, rules are inherently covered by the signature — no separate mechanism needed.

Test: enforce_mode_rejects_tampered_rule_annotation — signs a schema carrying all three rule kinds, weakens only the @require threshold, and confirms verify_files under enforce returns HashMismatch.

Audit story documented in docs/rule-ordering-reference.md §2: how a reviewer enumerates every rule gating an entity (the @require/@compute/@default annotations in the signed .schema; sf parse surfaces them; signature + trust bundle give provenance).