v1.9.1

[1.9.1] - 2026-06-23

• Bind the sealed maxClass to the signature at every consume path, closing a relabeling gap in the v1.9.0 enforce-by-class gate. maxClass lives in the unsigned evidence block; it rides under signature only through the binding decisionDerived.evidenceRef.digest == sha256: + JCS(evidence). v1.9.0 verified the record signature but never recomputed that digest, so relabeling a sealed maxClass to a permitted class left the record signature intact and the gate trusted the forgery. Now the sealed class is consumed only from a seal whose evidence binds; an unbound (relabeled) seal contributes no class and the gate fails closed. New evidence_binding_ok(receipt) in vaara.credential performs the check; the independent checker reports all_evidence_bound and gates maxClass on it; vaara enforce-by-class drops unbound receipts before gating and takes an optional --key to verify issuer signatures too.
• New deny_relabeled conformance vector in tests/vectors/class_gate_v0/: a seal whose maxClass was relabeled to a permitted class after signing. The record signature still verifies (all_signatures_ok true) but the evidence no longer binds (all_evidence_bound false), so the checker and the CLI both fail closed. This is the relabeling attack raised on cosai-oasis/ws4 #99; the vector proves it is rejected.
• Documented the integrity assumption that was previously silent: enforce_on_sealed_class and verify_contiguity read maxClass off the evidence as given and trust it; callers MUST pass receipts whose signature and evidence binding they have verified. The checker docstring and the vector README no longer claim the bound is under signature on the strength of the record signature alone.