docs: recognize ops-warden operational SSH credential lane

Add Operational SSH Path to platform architecture and move ops-warden
from out-of-scope to operational SSH dependency in responsibility-map.
Aligns with ops-warden WARDEN-WP-0006 stewardship work.

docs/platform-identity-security-architecture.md

@@ -214,6 +214,36 @@ identifies actors and workloads; flex-auth decides whether a credential
 or secret request is allowed; OpenBao stores, issues, audits, and revokes
 the resulting secret material.
 
+## Operational SSH Path
+
+Short-lived **SSH certificates** for host and ops reachability are a
+separate lane from OpenBao runtime secrets. ops-warden owns issuance;
+ops-bridge consumes certs for tunnels; railiance-infra deploys host trust
+and principals.
+
+```text
+Development worker (adm / agt / atm)
+        |
+        v
+ops-warden
+  actor inventory + TTL/principal policy
+  warden sign / cert_command / ops-ssh-wrapper
+  (signing via local CA or OpenBao SSH secrets engine API)
+        |
+        +-- ops-bridge (tunnel transport, cert_command consumer)
+        |
+        v
+SSH to host
+  principals matched via /etc/ssh/auth_principals/ (railiance-infra)
+```
+
+ops-warden also maintains **credential routing guidance** so workers do not
+mistake the SSH lane for OpenBao API keys or flex-auth policy decisions.
+Non-SSH credentials follow the Secret And Credential Path above.
+
+Future: flex-auth may gate `warden sign` before SSH engine signing
+(`ops-warden/wiki/PolicyGatedSigning.md`).
+
 ## Platform Root Custody
 
 Platform root authority is an accountable custody role, not a tenant admin role