fix(cmf): settle the extensions model and document the extension types

[araujof]

Description

Follow-up to #7, which added original CMF extensions alongside the flattened variables. That change surfaced how much of the model is undocumented and how differently the decision points read it.

Open items:

• Extensions vs flattened variables. Both paths now exist. Which one a policy author should use, and what happens when they disagree, is not written down anywhere.
• PDP interactions. The decision points do not agree on missing keys. The APL DSL treats a missing key as false. CEL raises "no such key" and CelResolver's default OnError::Deny turns that into a denial reporting a key error rather than a policy outcome. cedar-direct independently decided to inject empty defaults. feat: support original CMF extensions alongside flattened variables #7 fixed this for StringSet keys by emitting empty sets rather than omitting them, but as a rule applied across the bridge, not as a stated contract. Other types have not been checked.
• Skipped claims. subject.claims was left out of feat: support original CMF extensions alongside flattened variables #7 because mapping a dict object needs a new AttributeType. That gap should be closed or recorded as a decision.
• Documentation. The twelve extension slots in crates/ppe-apl-cmf/src/extensions_bridge.rs have no reference doc listing what each one carries, the attribute keys it produces, and the type of each.

Acceptance criteria

• A stated contract for what the bridge emits when a value is absent, per attribute type, not just StringSet. Every PDP is checked against it.
• The relationship between original extensions and flattened variables is documented, including which takes precedence.
• subject.claims is supported, or the reason it is not is recorded with what it would take.
• A reference doc covering all twelve slots, their keys, and their types.
• Tests that a policy written against a given key behaves the same on APL, CEL, cedar-direct, and OPA when the value is absent.