fix: compare structured binding fields, not a digest we cannot reproduce

The live proof in 03c0569 showed validate_decision_envelope rejecting every
real allow. The evaluator normalizes before hashing -- the request tenant is
copied onto subject and resource, and a registry hit copies type, tenant and
selected attributes onto the refs -- so binding.request_digest covers
material we never sent. Byte-equality against our unenriched request was
unsatisfiable, not merely mismatched.

THE RULE WAS ALREADY PUBLISHED. flex-auth's canonical-request-digest.md
section "Normalization" states the enrichment and tells consumers what to do
instead: compare structured binding fields to the proposed action, treat
request_digest as the evaluator's statement of what it hashed, and recompute
independently over the tuple the binding carries. I raised this with them as
an unpublished gap and asked them to pick between three shapes; it was in
their contract already and the answer was the first of the three. Nothing
was blocked on them, and this follows the published rule rather than one I
inferred.

- _require_binding_corresponds: everything we proposed must survive
  unchanged -- tenant, action, context, subject.id/type,
  resource.id/type/system, and every attribute we sent.
- Enrichment may add only type, tenant, attributes. Any other added field is
  refused, and an enriched tenant must be the request tenant, so a
  cross-tenant binding cannot arrive wearing our request's clothes.
- request_digest is still verified, now against binding_tuple(binding) for
  self-consistency rather than against material we never sent.
- The envelope's top-level subject/resource get the same rule; they are
  enriched too.

Proved against the artifact: the real decision:0f9c98f14545c42d now
validates, and the unrefreshed envelope is refused on lifetime -- reaching
the lifetime check at all is the evidence the binding checks pass on a real
decision. Negatives cover a restated resource.attributes.stage, a foreign
subject.tenant, and an unexpected enrichment field.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E4tNMAYcSQmZWUE4wqP4ij

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 715726@bnt-lap001
Assistant-Session: 80a42b32-cba6-4b23-8be0-68819b1a6092

docs/pdp-access-path.md

@@ -76,21 +76,40 @@ v1 shipped and was deployed with no `input.tenant` rule at all; a `rotate` under
 change is visible in the version string, and this engine refuses a v1 decision
 outright. See `docs/tenant-alignment.md`.
 
-## Known gap: the digest join does not hold against a real request
+## The digest join, and why it is not a digest comparison
 
-Proved live on 2026-09-07 and **not yet fixed**; the engine currently rejects
-every real allow, which is fail-closed and therefore safe to leave standing
-while the rule is published.
+Proved live on 2026-09-07, fixed the same day.
 
-The evaluator enriches the request from its registry before hashing — `subject`
-gains `attributes` and `tenant`, `resource` gains `tenant` — so
-`binding.request_digest` is a digest of material we did not send and cannot
-reproduce. `validate_decision_envelope` compares the binding against our
-unenriched request and fails with *"decision binding does not match request"*.
+The evaluator normalizes before hashing: the request tenant is copied onto
+`subject` and `resource`, and a registry hit copies `type`, `tenant` and
+selected `attributes` onto the refs. So `binding.request_digest` is over
+material we did not send and cannot reproduce, and the validator's original
+byte-equality check against our unenriched request rejected every real allow.
 
-Which fields the evaluator may enrich is flex-auth's contract to publish, not
-ours to infer. Guessing it would mean accepting a binding that differs from what
-we proposed in some way we decided was benign — the same fail-open shape as a
-guessed digest exclusion or a guessed vocabulary mapping. Raised with flex-auth;
-staying fail-closed and naming the missing rule is the correct posture until
-they answer.
+flex-auth's `canonical-request-digest.md` already published the consumer rule,
+and the fix follows it rather than inventing one:
+
+> A consumer that re-hashes the **original** unenriched request will not match a
+> decision that turned on registry attributes. Compare structured `binding`
+> fields to the proposed action, and treat `request_digest` as the evaluator's
+> statement of what it hashed. To recompute independently, hash the same
+> normalized tuple the binding carries.
+
+`validate_decision_envelope` now does exactly that:
+
+- **Structured correspondence.** Everything we proposed — tenant, action,
+  context, `subject.id`/`type`, `resource.id`/`type`/`system` and every
+  attribute we sent — must survive unchanged in the binding.
+- **Enrichment only where the contract permits it.** A ref may gain `type`,
+  `tenant` and `attributes`; any other added field is refused. An enriched
+  `tenant` must be the request's tenant, so a cross-tenant binding cannot arrive
+  wearing our request's clothes.
+- **Digest self-consistency.** `request_digest` is recomputed over the
+  normalized tuple the binding carries, per the contract's own instruction. It
+  is still checked — just for coherence of the binding rather than against
+  material we never sent.
+
+The lesson worth keeping: the replay fixtures could not catch this, because
+`_request_from()` rebuilds the request from the binding, so the tests hashed the
+evaluator's output and compared it to the evaluator's output. Only a real
+request through this access path exposed it.

docs/tenant-alignment.md

@@ -116,9 +116,9 @@ alone.
   port-forward` plus a bounded `TokenRequest` token; see
   `docs/pdp-access-path.md`. Adopted and enforced in
   `decision_check.require_supported_pdp_address`.
-- The evaluator's **enrichment rule**: `binding` carries registry-enriched
-  `subject.attributes`, `subject.tenant` and `resource.tenant` that we did not
-  send, so the digest join fails against a real request. flex-auth's to publish.
+- ~~The evaluator's enrichment rule~~ — **already published** in flex-auth's
+  `canonical-request-digest.md` ("Normalization"), and now implemented. See
+  `docs/pdp-access-path.md`.
 
 ## Hazard: the Service DNS name resolves here, to the wrong host