Add OpenBao runtime secret authority; complete NK-WP-0006/0007/0008

Refine the recursive platform security architecture to make OpenBao the
canonical runtime secret authority, with SOPS/age, K8s Secrets, and the
emergency bundle reframed as bootstrap/delivery/break-glass mechanisms.

- credential-management standard v0.2: add OpenBao runtime authority
  section, rotation rules, and prohibited patterns (OpenBao-as-PDP,
  tenant platform-root)
- platform-identity-security-architecture: mark implemented; add
  flex-auth/Topaz implications, Coulomb onboarding path, and a
  production-readiness checklist
- NK-WP-0004/0005: document bootstrap-to-OpenBao handoff boundary
- NK-WP-0006/0007: status -> done with implementation reviews; add
  recursive platform/tenant split and OpenBao broker/audit role for
  object-storage STS vending
- NK-WP-0008: status -> done; repoint corpus to infospace-bench
- new ADR-0007 (orchestration boundary), ADR-0008 (STS vending
  boundary), and the object-storage STS credential-vending architecture

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

workplans/NK-WP-0004-credential-management-foundation.md

@@ -8,7 +8,7 @@ status: done
 owner: custodian
 topic_slug: netkingdom
 created: "2026-03-20"
-updated: "2026-03-20"
+updated: "2026-05-18"
 state_hub_workstream_id: "d9cf7c4b-886b-4cd1-ad7b-99c4e1929c9e"
 ---
 
@@ -68,10 +68,34 @@ Operator
       warns about time-sensitive steps like enckey-bootstrap)
 ```
 
+## NK-WP-0006 Runtime Secret Refinement
+
+This workplan remains the bootstrap credential foundation. With OpenBao in
+the platform stack, its outputs are not the final runtime secret model.
+They establish enough trust to bring up identity, MFA, and platform
+services safely.
+
+Trust-state mapping:
+
+- bare host and cluster trust are established by Railiance layers;
+- bootstrap secret trust is established by SOPS/age, encrypted bundles,
+  emergency material, and Kubernetes Secret injection;
+- bootstrap identity trust is established by local/key-cape/bootstrap
+  identity paths;
+- runtime secret trust begins only after OpenBao is deployed,
+  initialized, unsealed or auto-unsealed by the approved mechanism,
+  audited, backed up, and ready to issue scoped secrets or dynamic
+  credentials.
+
+After runtime secret trust exists, Kubernetes Secrets created here should
+be treated as bootstrap artifacts, delivery caches, or compatibility
+mechanisms. Long-lived workload secret authority belongs in OpenBao,
+governed by NetKingdom policy and Railiance platform operations.
+
 ## Dependency on canon standard
 
 All design decisions in this workplan follow
-`canon/standards/credential-management_v0.1.md`.
+`canon/standards/credential-management_v0.2.md`.
 The KeePassXC group structure, phase model, SOPS policy, and prohibited
 patterns defined there are normative. This workplan implements them.