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

pkg/api/canonical.go

@@ -276,6 +276,25 @@ type DecisionBinding struct {
 	// identity and must not be used as one: two requests differing only in
 	// which approval was presented share it, and the decision does not.
 	ApprovalBindingDigest string `json:"approval_binding_digest,omitempty" yaml:"approval_binding_digest,omitempty"`
+
+	// SubmittedRequestDigest is RequestDigest over the request exactly as the
+	// consumer sent it, before the evaluator overlays registry facts onto the
+	// subject and resource.
+	//
+	// It exists because RequestDigest is not consumer-computable and was
+	// published as though it were. The evaluator hashes the ENRICHED request —
+	// subject.tenant, subject.attributes, and resource attributes the registry
+	// contributed — and the registry is flex-auth's, so a consumer recomputing
+	// the digest over what it sent gets a different value on every real allow.
+	// secrets-engine found this on its first live request (FLEX-DEC-2026-012).
+	//
+	// This is the digest a PEP compares for §6.4 obligation 2's replay test.
+	// Nothing is lost by hashing the pre-enrichment form: enrichment is a
+	// function of the request and the registry snapshot, and
+	// provenance.registry_snapshot_digest already pins the snapshot, so
+	// SubmittedRequestDigest together with that digest identifies the evaluated
+	// request completely.
+	SubmittedRequestDigest string `json:"submitted_request_digest,omitempty" yaml:"submitted_request_digest,omitempty"`
 }
 
 // ApprovalContextKey is the context key carrying an approval-engine
@@ -296,6 +315,10 @@ type requestDigestMaterial struct {
 
 // NewDecisionBinding returns a stable structured binding for the exact request
 // an evaluator consumed.
+//
+// Prefer NewDecisionBindingFor, which also records the digest of the request as
+// submitted. This form leaves SubmittedRequestDigest empty, which reads as "the
+// evaluator did not record one" rather than "the two are equal".
 func NewDecisionBinding(request CheckRequest) *DecisionBinding {
 	contextCopy := make(map[string]any, len(request.Context))
 	for key, value := range request.Context {
@@ -315,6 +338,19 @@ func NewDecisionBinding(request CheckRequest) *DecisionBinding {
 	return binding
 }
 
+// NewDecisionBindingFor records the binding of the evaluated request together
+// with the digest of the request as submitted.
+//
+// The two arguments are the same request before and after the evaluator
+// overlaid registry facts. Where a request named nothing the registry knows they
+// are equal, and the field is emitted anyway: a consumer that only sees it on
+// enriched decisions would build a check that passes by absence.
+func NewDecisionBindingFor(evaluated, submitted CheckRequest) *DecisionBinding {
+	binding := NewDecisionBinding(evaluated)
+	binding.SubmittedRequestDigest = RequestDigest(submitted)
+	return binding
+}
+
 // ApprovalBindingDigest is RequestDigest over the same material with the
 // approval claim removed from context.
 //