correct exact source case-type pin

Assistant: codex
Assistant-Model: gpt-6.1-sol
Assistant-Session: 01a126e1-76f8-7643-8cf3-e93336539ade

docs/keycape-client-secret-generate-type-pin-review.md

@@ -0,0 +1,30 @@
+# Exact case-type pin correction — 2026-10-10
+
+The broker's `CASE_TYPE` still required browser-RP @1.0 after the founder
+authorized @1.1 and net-kingdom re-pinned the accepted Forgejo case. That made
+the real case fail `case_type_mismatch` before any backend call.
+
+`keycape_client_secret_generate.py` now accepts exactly
+`oidc-browser-relying-party@1.1`; @1.0, arbitrary later versions and other
+types remain refused. Existing exact-byte case-ref, materialized status,
+client match, confidential/reserved identity, caller/root/agent boundary,
+scoped grant, CAS0 create-once, silent receipt and revocation checks are unchanged.
+
+Authority evidence: NK-WP-0048, 2026-10-10 founder go for 1.1; source type
+`security-case-types/oidc-browser-relying-party/type.yaml` version 1.1,
+acknowledged; accepted Forgejo case carries @1.1. No case status, live backend
+or credential changed during this correction.
+
+Regression uses the actual accepted Forgejo file shape with materialized
+status solely in the offline fake test fixture. Real accepted (unmaterialized)
+case remains refused. Ten subprocess CLI tests pass against a fake bao in an
+isolated temporary tree, including silence, exact mismatch before any backend
+call, reserved/agent/root identity guards, scoped token delivery, CAS0/race and
+revocation. No live broker execution is claimed.
+
+The materialization/run circularity remains an owner contract question:
+MASON-WP-0010 describes mint-secret as needed before materialized, while
+WARDEN-WP-0044 and this broker require materialized before mint-secret.
+Owner review should define structural materialization with exact applied reader
+receipts, then follow-through creates custody and verifies delivery. This
+correction does not silently relax status gating or assert those receipts.