feat(mvp): working secrets-engine CLI for the whynot-design npm publish lane

Implements SECRETS-WP-0002 end to end as a uv-managed Python package:

- catalog: non-secret lane registry + strict validator (build/test/prod)
- stage roles + OpenBao ACL policies; guards refuse wildcards, sys/, identity/,
  admin names, and cross-stage paths before any backend call
- plan/apply: dry-run-first, idempotent policy + approle apply, decision-gated
- decisions: State Hub lookup with local-fixture fallback; non-secret evidence
  to JSONL + hub progress, scrubbed of any value
- provision/verify: mode-0600 file import + generated test values; positive/
  negative checks that never print the value
- exec delivery: `exec --catalog ... -- npm publish` injects the token via a
  temp .npmrc for the child only, cleaned up on exit/failure/interrupt
- ops-warden routing contract + hardening backlog docs
- 34 tests incl. live OpenBao integration; scripts/demo-e2e.sh runs the full
  chain against a throwaway bao dev server

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

docs/netkingdom-security-infrastructure.md

@@ -0,0 +1,22 @@
+# NetKingdom Security Infrastructure Boundary
+
+The canonical document lives in the NetKingdom repository:
+
+```text
+net-kingdom/docs/secrets-engine-security-infrastructure-boundary.md
+```
+
+Local checkout path:
+
+```text
+/home/worsch/net-kingdom/docs/secrets-engine-security-infrastructure-boundary.md
+```
+
+This secrets-engine file is intentionally only a pointer. The canonical document
+belongs to NetKingdom because it defines cross-system security infrastructure
+responsibilities and boundaries across OpenBao, flex-auth, user-engine/key-cape,
+ops-warden, ops-bridge, info-tech-canon, State Hub, and agents.
+
+secrets-engine consumes that boundary and implements the secrets workflow,
+catalog, stage policies, OpenBao apply/delivery mechanics, and evidence model
+that the canonical document assigns to it.