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

workplans/SECRETS-WP-0009-glas-claude-native-delivery.md

@@ -96,6 +96,49 @@ authorization. No unsafe-demo switch and no human runtime token will be used to
 reach a prod lane. This task stays `wait`: activation is blocked on the owner
 access path, not on engine work or on approval shape.
 
+Digest join corrected 2026-09-07. The live proof from 2026-09-06 (commit
+`03c0569`) showed `validate_decision_envelope` rejecting every real allow. The
+cause and the fix are both now settled, and the fix follows a published rule
+rather than an inferred one.
+
+- **Cause.** 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. `binding.request_digest` is
+  therefore over material we never sent and cannot reproduce, so byte-equality
+  against our unenriched request is unsatisfiable, not merely mismatched.
+- **The rule was already published.** flex-auth's `canonical-request-digest.md`
+  section "Normalization" states it, and instructs consumers to compare
+  structured `binding` fields to the proposed action and treat `request_digest`
+  as the evaluator's statement of what it hashed, recomputing independently over
+  the tuple the binding carries. Correction to the previous note: this repo
+  raised it with flex-auth as an unpublished gap and asked them to choose
+  between three shapes. It was already in their contract, and the answer was the
+  first of the three. Nothing was blocked on them.
+- **Implemented.** `_require_binding_corresponds` enforces that everything we
+  proposed survives 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 checked, now
+  against `binding_tuple(binding)` for self-consistency.
+- **Proved against the artifact.** `tests/test_live_decision_enrichment.py`
+  validates the real `decision:0f9c98f14545c42d` under the corrected rule, and
+  separately asserts the unrefreshed envelope is refused on lifetime — reaching
+  the lifetime check at all is the evidence every binding check now passes on a
+  real decision. Negative tests cover a restated `resource.attributes.stage`, a
+  foreign `subject.tenant`, and an unexpected enrichment field.
+- **Why the fixtures could not catch it.** `_request_from()` rebuilds the
+  request out of the binding, i.e. the already-enriched form, so every digest
+  assertion hashed the evaluator's output and compared it to the evaluator's
+  output. The defect survived the excluded-fields fix, the
+  `approval_binding_digest` fix and the tenant fix because all three were tested
+  that way. Only a real request through the owner access path exposed it.
+
+Remaining before activation is now one external dependency, not two:
+approval-engine must serve the claim endpoint so protocol step 1 can run and
+`GH-DEC-2026-003` consume-before-OpenBao can be satisfied. The decision path
+itself is proved end to end against the deployed pin.
+
 Depends on SECRETS-WP-0007-T04 and SECRETS-WP-0008-T02/T06: canonical production
 authorization, successful consume and scoped service authority must exist.
 Current production exec refuses before OpenBao because durable access-engine