fix(decision): registry facts win over caller-supplied attributes

secrets-engine's first live request rejected our allow: binding.
request_digest is computed over material they never sent, because we
enrich subject and resource from the registry before hashing. Answering
that meant reading the enrichment path, which had a worse defect in it.

Enrichment was additive-if-absent — addAttribute wrote a registry value
only where the request had no value for that key. So where a caller
supplied a key, the caller's value won and the registry's never applied.
Every registry ceiling and allowlist was advisory. Verified against the
shipped ops-warden package, each one added key on an otherwise-denied
request:

  max_ttl_hours: 99      registry says 8    -> allowed a 12h certificate
  allowed_principals     registry allowlist -> disallowed_principal bypassed
  allowed_subjects       registry allowlist -> unknown_subject bypassed

The third is the one to read twice: a subject the registry does not know
authorized itself by naming itself in the allowlist it was being checked
against.

Not remotely reachable today — the PEP builds the CheckRequest,
ops-warden sends no resource.attributes, and enforce admits one identity.
It is a defence-in-depth failure: any path that lets attacker-influenced
data into a CheckRequest field became a full policy bypass rather than a
bounded input problem. Callers sending resource.attributes is not
hypothetical; secrets-engine does it on every request.

Registry facts now win, and diagnostics.registry_overrode names every
displaced key, because a registry that silently discards a contradicting
claim hides that a caller asserted authority it did not have.

subject.type is carved out, and the reason is a finding of its own.
Making the registry win there denied every secrets-engine allow: the
registry's type is CARING vocabulary (Human, Agent, Automation, Service)
and the request's is the protected system's actor vocabulary (service,
adm, agt, atm). Two fields sharing a name; substituting one for the other
is translation rather than identity, which GH-DEC-2026-008 ruled against.
Note what surfaced it — the registry's type had been dead data since the
field existed, because the caller's value always won.

Also publishes binding.submitted_request_digest, over the request exactly
as sent. request_digest was published as the consumer replay test and
cannot be one. Nothing is lost hashing the pre-enrichment form:
enrichment is a function of the request and the snapshot, and
registry_snapshot_digest already pins the snapshot.

Existing pins do not move. All three replay fixtures' request_digest and
approval_binding_digest values are byte-identical — those requests
contradict no registry fact. A field to add, not a value to correct.

Regression tests verified failing against the old behaviour before being
kept. FLEX-DEC-2026-012; FLEX-WP-0025 carries the residual, that a policy
still cannot tell a fact from an assertion.

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

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 715613@bnt-lap001
Assistant-Session: fabd95c1-4c9e-4080-8849-8707ae025f80

docs/decision-record-contract.md

@@ -29,6 +29,8 @@ same shape.
 | --- | --- |
 | `contract_version` | `flex-auth.decision-record.v1` |
 | `binding` | Structured subject, action, resource, context, and `request_digest` |
+| `binding.submitted_request_digest` | Digest over the request **exactly as sent**, before registry enrichment. **This is the consumer's replay test** for §6.4 obligation 2 |
+| `binding.submitted_request_digest` | Digest over the request **exactly as sent**, before registry enrichment. **This is the consumer's replay test** for §6.4 obligation 2 |
 | `binding.approval_binding_digest` | Present only when the request carried `context.approval`. The digest an approval's `pdp_digest` must equal — see [`canonical-request-digest.md`](canonical-request-digest.md). Not a replay identity |
 | `lifetime` | **Required on every allow.** A TTL with `not_before` and `expires_at` |
 | `provenance.policy_package` / `policy_version` | Named package pin |
@@ -81,3 +83,39 @@ A detached signature over the canonical envelope is the intended fix
 (`FLEX-WP-0024`). Until it lands, responder authenticity comes from the channel
 alone — and of the available channels only `kubectl port-forward` supplies it,
 by targeting one named pod over the API server's TLS with no DNS name resolved.
+
+## `request_digest` is not the consumer's replay test
+
+Correction, 2026-09-07. `request_digest` is computed over the **enriched**
+request — after the evaluator overlays registry facts onto subject and resource —
+so a consumer recomputing it over what it sent gets a different value on every
+request whose subject or resource the registry knows. It was published as the
+§6.4.2 replay test and cannot be one, because the registry is flex-auth's.
+
+**Compare `binding.submitted_request_digest` instead.** It is `RequestDigest`
+over the request exactly as received, and together with
+`provenance.registry_snapshot_digest` it identifies the evaluated request
+completely — enrichment is a function of those two. `request_digest` keeps its
+value and its meaning as flex-auth's own audit-replay identity.
+
+What the evaluator may add, which value wins where the two disagree, and the
+stated residual are in [`request-enrichment.md`](request-enrichment.md)
+(`FLEX-DEC-2026-012`).
+
+## `request_digest` is not the consumer's replay test
+
+Correction, 2026-09-07. `request_digest` is computed over the **enriched**
+request — after the evaluator overlays registry facts onto subject and resource —
+so a consumer recomputing it over what it sent gets a different value on every
+request whose subject or resource the registry knows. It was published as the
+§6.4.2 replay test and cannot be one, because the registry is flex-auth's.
+
+**Compare `binding.submitted_request_digest` instead.** It is `RequestDigest`
+over the request exactly as received, and together with
+`provenance.registry_snapshot_digest` it identifies the evaluated request
+completely — enrichment is a function of those two. `request_digest` keeps its
+value and its meaning as flex-auth's own audit-replay identity.
+
+What the evaluator may add, which value wins where the two disagree, and the
+stated residual are in [`request-enrichment.md`](request-enrichment.md)
+(`FLEX-DEC-2026-012`).