Add configurable crypto policy enforcement layer

[dnovick]

Add support for configurable crypto policy enforcement above the guarantees already enforced by the library API.

Motivation:

Some users, especially enterprise users, may need to enforce organization-specific cryptographic policies that go beyond the library's built-in safety checks. Examples could include approved algorithm lists, disallowed legacy algorithms, minimum key sizes, provider restrictions, mode restrictions, or environment-specific compliance rules.

Potential scope:

• Define a policy abstraction that can approve or reject requested cryptographic operations before execution.
• Allow policies to express algorithm usage rules, key size requirements, provider/backend constraints, and possibly operation-specific requirements.
• Ensure policy enforcement is explicit, testable, and does not weaken the existing API-level safety guarantees.
• Decide whether policies should be configured at context/session level, per operation, build time, runtime, or some combination.
• Provide clear error reporting when an operation is rejected by policy.
• Consider how this should apply to both the library API and CLI.

Open design questions:

• What is the right policy representation: code callbacks, structured config, compiled profiles, or named built-in policy sets?
• Should the default behavior remain unchanged unless a policy is configured?
• How should policies interact with provider capabilities and existing algorithm negotiation?
• How much compliance vocabulary should be built in versus left to application-level configuration?

This is not currently top priority, but should be tracked for future design work.