Publish approval_binding_digest: a claim cannot name the request carrying it

secrets-engine confirmed T03, and re-verifying against the regenerated
destroy fixture found something neither repository can fix alone: a
pdp_digest recorded at issue time can never equal the request_digest of a
request that carries the claim in its context, because the claim is part
of the context that is hashed. Embedding the claim changes the very
digest the claim would need to name.

Not fixture staleness. It holds for every dual-control request whose
claim travels in context -- the shape GH-DEC-2026-008 had just ruled
mandatory. Left unresolved that ruling was unimplementable for exactly
the case it was written for, and destroy would have been permanently
un-allowable in production, failing closed forever on a check that could
never pass.

flex-auth owns the canonical request digest, so the fix is ours.
binding.approval_binding_digest is the same material with
context.approval removed, emitted only when a claim was carried. An
approval issued against a claim-free Check records that Check's
request_digest; the claim-bearing request reproduces it here.

DELIBERATELY ADDITIVE, and the reason matters. The tempting fix is to
drop context.approval from request_digest entirely. That is wrong:
request_digest is the replay identity, and two requests differing only in
which approval was presented must not share one, because their decisions
differ -- one allows, the other denies dual_control_required. Collapsing
them would let an allow obtained with a valid claim be replayed against a
request carrying none. So request_digest still covers the claim and still
moves; approval_binding_digest deliberately does not, and is documented
as not a replay identity. The tests assert the two functions DISAGREE on
a claim-bearing request, which is approval-engine's formulation of how to
defend a distinction that looks like duplication.

The fixture now demonstrates the property rather than asserting it: its
claim's pdp_digest equals the envelope's approval_binding_digest with
pdp_path true, and changing the claim's contents moved request_digest
while leaving approval_binding_digest untouched. Two files a consumer can
diff.

Also picked up approval-engine's new required binding.pdp_path via the
cross-repo schema test added yesterday -- which is the test doing exactly
what it was built for, one day later.

T03 is done. secrets-engine's own digest-material defect, which our two
real envelopes caught, is recorded in the workplan.

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

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 412054@bnt-lap001
Assistant-Session: 3968fae1-8d59-4209-9bd6-c22594b8ab19

decisions/decisions.md

@@ -879,3 +879,130 @@ reserved-but-unpublished coordinate from `FLEX-DEC-2026-005`.
 - No revisit trigger remains open on flex-auth's side. If the composed object is
   ever revisited, it needs a fresh argument, not G3.
 
+## FLEX-DEC-2026-007 — A claim cannot name the request that carries it: publish approval_binding_digest
+
+```yaml
+id: FLEX-DEC-2026-007
+kind: decision
+title: 'A claim cannot name the request that carries it: publish approval_binding_digest'
+status: resolved
+origin: cross-repo
+origin_ref: secrets-engine T03 re-verification / GH-DEC-2026-008
+owner: flex-auth
+affects:
+- flex-auth
+- secrets-engine
+- approval-engine
+- gate-house
+requested_dispositions:
+- resolve
+decided_by: flex-auth (access-engine / PDP)
+rationale: 'secrets-engine found that an approval pdp_digest recorded at issue time
+  can never equal the request_digest of a request that carries the claim inside its
+  hashed context, because the claim is part of the context that is hashed. The circularity
+  is structural, not a fixture defect, and it made GH-DEC-2026-008 unimplementable
+  for exactly the dual-control case it was written for. flex-auth owns the canonical
+  request digest, so the resolution is ours. Publishing binding.approval_binding_digest:
+  the same digest computed with context.approval removed, present only when a claim
+  was carried, stable across attaching the claim, and therefore nameable by a pdp_digest
+  recorded at issue. Deliberately additive rather than a redefinition: request_digest
+  keeps covering the claim and remains the replay identity, because two requests differing
+  only in which approval was presented must not share a replay identity when one allows
+  and the other denies dual_control_required. Tests assert the two functions disagree
+  on a claim-bearing request and agree on a claim-free one.'
+created: '2026-09-06T12:52:06.960329Z'
+updated: '2026-09-06T12:52:06.960329Z'
+```
+
+## Context
+
+`secrets-engine` confirmed `FLEX-WP-0021-T03` — both replay envelopes reproduce
+— and in doing so found a defect in their own digest join: they were hashing
+`id`, `policy_version`, and `caring_context`, which
+[`canonical-request-digest.md`](../docs/canonical-request-digest.md) excludes.
+Their previously pinned constant had been computed with `id` inside the
+material, so it was wrong and its passing proved nothing. Two real envelopes
+caught it.
+
+Re-verifying against the regenerated `destroy` fixture, they then found
+something neither repository can fix alone.
+
+## The finding
+
+> A `pdp_digest` recorded at issue time cannot equal the `request_digest` of a
+> request that carries the claim in its context.
+
+Completing `context.approval` to a full approval-claim is what moved the
+`destroy` fixture's digest — because context is part of the digest material.
+That is correct behaviour, and it is circular: embedding the claim changes the
+very digest the claim would need to name.
+
+It is not fixture staleness. It holds for every dual-control request whose claim
+travels in context, which is the shape `GH-DEC-2026-008` had just ruled
+mandatory: `claim.binding.pdp_digest` must equal the decision's request digest,
+and a claim without one must not be used on the PDP path. Left unresolved, the
+ruling would have been unimplementable for exactly the case it was written for —
+and `destroy` would have been permanently un-allowable in production, failing
+closed forever on a check that could never pass.
+
+## Disposition
+
+**flex-auth resolves it, because flex-auth owns the digest.** `secrets-engine`
+raised it correctly and could not fix it; `approval-engine` records the value but
+does not define it; gate-house ruled on the correspondence but the mechanism is
+the PDP's.
+
+`binding.approval_binding_digest` is published: the same canonical material with
+`context.approval` removed, emitted only when the request carried a claim.
+
+```text
+claim.binding.pdp_digest == decision.binding.approval_binding_digest
+```
+
+An approval issued against a claim-free Check records that Check's
+`request_digest`; the later claim-bearing request reproduces the same value in
+`approval_binding_digest`. The circularity is broken because the excluded key is
+exactly the one whose contents would otherwise perturb it.
+
+### Why this is a second digest and not a redefinition
+
+The tempting fix is to drop `context.approval` from `request_digest` entirely.
+That is wrong, and the reason is worth recording because it is not obvious.
+
+`request_digest` is the §6.4.2 replay identity. Two requests differing only in
+which approval was presented **must not share one**, because their decisions
+differ: one allows, the other denies `dual_control_required`. Collapsing the two
+digests would let an allow obtained with a valid claim be replayed against a
+request carrying none. The decision is not a function of the approval-excluded
+material, so the approval-excluded material cannot be the replay identity.
+
+So `request_digest` still covers the claim and still moves when it changes.
+`approval_binding_digest` deliberately does not move, and is documented as **not
+a replay identity**. `pkg/api/approval_binding_test.go` asserts the two
+functions *disagree* on a claim-bearing request — a test that a distinction is
+real is how a distinction that looks like duplication is defended, which is
+`approval-engine`'s formulation and it applies here.
+
+### The fixture demonstrates it rather than asserting it
+
+`examples/secrets-engine/replay/decision_destroy_dual_control.json` now carries a
+claim whose `pdp_digest` equals the envelope's `approval_binding_digest`, with
+`pdp_path: true`. Changing the claim's contents moved `request_digest` and left
+`approval_binding_digest` untouched, which is the whole property, visible in two
+files a consumer can diff.
+
+## Consequences
+
+- Additive to `flex-auth.decision-record.v1`. No existing digest changed
+  meaning, and no consumer that never sends `context.approval` sees the field
+  at all — `approval_binding_digest` is omitted rather than duplicated onto
+  every ordinary decision.
+- `secrets-engine` must compare `pdp_digest` to `approval_binding_digest`, never
+  to `request_digest`. Their fixture pins move because the fixture's claim
+  changed; the property does not.
+- `approval-engine` needs no change. The value they record at issue is already
+  the right one.
+- The three shapes `secrets-engine` offered are answered by the first: the
+  digest an approval names is computed without `context.approval`, and it is now
+  stated in the contract rather than left to be discovered.
+