[Security audit] Require exact fingerprints and justification for raw-HTML exceptions

[cssbruno]

Problem

Raw-HTML audit exceptions are too broad. The engine gathers allowlist state across resolved frontend policies, while exceptions are identified mainly by source, owner, and field. That can allow a stale or overly broad exception to suppress a different sink than intended.

Evidence

• Raw HTML posture records ownerKind, ownerId, field, and source.
• Policy exceptions can be evaluated against resolved frontend audit policies without a stable sink fingerprint or expiry contract.
• Exceptions do not require sanitizer/trusted-type evidence.

Expected Fix

Require an exact raw-HTML sink fingerprint plus owner, justification, expiry, and expected sanitizer or trusted-type evidence before suppressing a raw-HTML finding.

Acceptance Criteria

• Each raw-HTML sink has a stable fingerprint derived from owner, source, field/expression, and generated sink identity.
• Exceptions must specify the exact fingerprint they suppress.
• Exceptions require owner, justification, expiry, and expected sanitizer/trusted-type contract.
• Expired or unmatched exceptions produce findings.
• Policy output distinguishes active, expired, unmatched, and malformed exceptions.
• Tests cover exact match, stale source movement, changed field/expression, expired exception, and unmatched exception.

Related: #556 tracks evidence classification and waiver states.