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

examples/secrets-engine/replay/README.md

@@ -31,6 +31,30 @@ go run ./cmd/flex-auth check \
 
 Verified identical across two runs.
 
+**Regenerated 2026-09-07 — `submitted_request_digest` added; every existing
+digest unchanged.** From `FLEX-DEC-2026-012`, which `secrets-engine` found by
+running against the live pin.
+
+`request_digest` is computed over the **enriched** request — after the evaluator
+overlays registry facts onto subject and resource — so it is not
+consumer-computable and never was. Pin **`submitted_request_digest`** instead:
+it is the digest over the request exactly as sent, and it is the §6.4.2 replay
+test. `request_digest` keeps both its meaning as flex-auth's own audit-replay
+identity and its exact value here — `de67324f…`, `c749ee2d…`, `c9c6e6f8…` are
+unchanged, as is `approval_binding_digest` at `fa07bec…`. The enrichment
+precedence changed in the same decision but these three requests contradict no
+registry fact, so nothing they hash moved. **Nothing you have pinned needs
+re-pinning; there is a new field to add, not an old one to correct.**
+
+| Field | `rotate` | `destroy` | `wrong-tenant` |
+| --- | --- | --- | --- |
+| `binding.submitted_request_digest` | `sha256:41c8fc08…` | `sha256:c605a9ec…` | `sha256:9aab6de9…` |
+
+A consumer that pinned `request_digest` from these files was pinning a value it
+could not have computed itself — it matched because it was copied from our
+output, not derived. That is the defect `submitted_request_digest` closes: the
+same assertion now has a value you can recompute from the request you sent.
+
 **Regenerated at `v2`, 2026-09-06.** The package gained the tenant rule it had
 been missing, so `provenance.policy_version` is now `v2` and
 `policy_package_digest` moved from `sha256:fe0070b7…bd8c` to