Document compliance and freeze matrix across vault operations

[hpmaxi]

Priority

Medium — should be addressed soon

User story / Problem statement

Currently, compliance and identity rules across investor statuses (Allowlisted, De-listed, Frozen) are scattered across multiple discussions without a single authoritative specification matrix. Different vault actions (request_deposit, cancel_deposit, claim_deposit, request_redeem, cancel_redeem, claim_redeem, transfer) have distinct regulatory requirements. Without an explicit matrix, contract implementations and SEP-57 token hooks risk inconsistencies.

Expected outcome

A documented specification matrix (in docs/COMPLIANCE_MATRIX.md or docs/DECISIONS.md) defining the allowed, refused, or exit-only behavior for every investor state across all vault lifecycle entrypoints.

Acceptance criteria

• A matrix covers states: Allowlisted, De-listed, Frozen across entrypoints: request_deposit, cancel_deposit, claim_deposit, request_redeem, cancel_redeem, claim_redeem, and transfer.
• Explicitly defines deposit cancellation for de-listed investors (allowed, returning settlement asset).
• Explicitly defines redemption cancellation for de-listed and frozen investors (refused; cannot return shares; exit proceeds via cash claim).
• Explicitly defines claim deposit behavior if an investor is de-listed between request and claim.
• Verified against SEP-57 compliance hooks and OZ RWA token behavior.

Technical notes

Consolidates decisions from #48 and coordinates requirements across #74 and #78.

Refs: ARCHITECTURE §4.4 · findings: F-037