Add compliance gating design rationale

[meetdarc-tech]

Summary

This PR adds a design-rationale document explaining why the protocol uses an explicit on-chain compliance gate rather than alternative patterns such as client-side allowlists, oracle-fed sanctions feeds, or zero-knowledge attestations.

What changed

• Added docs/compliance-gating-design.md
• Documented the protocol’s current model: admin-managed allow/block state stored on-chain and enforced through Compliance::is_allowed
• Explains the trade-offs of each alternative pattern in clear, auditable terms
• Captures the rationale for the existing design so future maintainers and auditors can understand why the current implementation was chosen

Why this design

The current compliance approach is intentionally not a soft client-only policy. The protocol stores the decision in contract state and enforces it automatically in the settlement flow. This makes the compliance gate deterministic, inspectable, and enforceable at the protocol boundary.

The document compares that model against:

• purely off-chain allowlist enforcement
• oracle-based sanctions feed integration
• zero-knowledge attestation-based compliance proofs

Each alternative is discussed in terms of its trust assumptions, operational trade-offs, and fit with this protocol’s public auditability needs.

Scope

This is documentation-only. It does not change behavior, ABI, storage schema, or runtime logic.

closes #476

[drips-wave]

@meetdarc-tech Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits.

You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀

Learn more about application limits