feat(storage): implement Phase 21 PostgreSQL/PostGIS persistence

[404khai]

Phase 20 loses operational authority and original retry outcomes when its process stops. Phase 21 adds opt-in PostgreSQL/PostGIS persistence: restart restores the same namespace, command/observation recognition, accepted terms, frozen execution, revisions and allocators before serving requests.

• Add roadrunner-storage with checksum-pinned offline migrations, normalized current facts, spatial positions/routes, retained graph/traffic artifacts, decisions/history and isolated simulation inputs/results.
• Publish business effects, original terminal outcomes and immutable outbox obligations atomically under a session writer lease and monotonic fence. Recheck temporal certificates in a deferred SQL COMMIT gate; retire failed writers and refuse cached authority.
• Require an independently locked/fsynced acknowledgement anchor so database rollback cannot erase acknowledged work. Verify immutable receipt ancestry when reconciling an acknowledgement failure after COMMIT.
• Integrate the existing API through blocking workers, preserve accepted work across HTTP disconnects, retain OpenAPI/Swagger, and document migration, restart, backup, retention and deployment constraints.

Validation: formatting and strict workspace Clippy pass; 234 workspace tests pass. All five opt-in real PostgreSQL/PostGIS transaction tests and seven actual process/fault cases pass, including SIGKILL during partial SQL writes, frozen restoration, lost response/retry and expiry during deferred COMMIT. Add a dedicated PostgreSQL/PostGIS CI job and raw release HTTP benchmark evidence with 30 runs per workload.

Supported scope is one PostgreSQL primary with explicit trusted-local NoTLS operation and a separately protected acknowledgement anchor. Automatic failover, global fencing of writable physical clones, production TLS/role provisioning and Phase 22 event delivery are deferred. Tiny loopback measurements establish a baseline, not a scalability claim.

See docs/persistence.md, docs/phase-21-completion.md and docs/evidence/phase-21-verification.json for the run guide, contracts and recorded evidence.

[gitguardian]

⚠️ GitGuardian has uncovered 2 secrets following the scan of your pull request.

Please consider investigating the findings and remediating the incidents. Failure to do so may lead to compromising the associated services or software components.

🔎 Detected hardcoded secrets in your pull request

GitGuardian id	GitGuardian status	Secret	Commit	Filename
24885935	Triggered	Generic Password	083d479	.github/workflows/ci.yml	View secret
24885935	Triggered	Generic Password	083d479	.github/workflows/ci.yml	View secret

🛠 Guidelines to remediate hardcoded secrets

1. Understand the implications of revoking this secret by investigating where it is used in your code.
2. Replace and store your secrets safely. Learn here the best practices.
3. Revoke and rotate these secrets.
4. If possible, rewrite git history. Rewriting git history is not a trivial act. You might completely break other contributing developers' workflow and you risk accidentally deleting legitimate data.

To avoid such incidents in the future consider

• following these best practices for managing and storing secrets including API keys and other credentials
• install secret detection on pre-commit to catch secret before it leaves your machine and ease remediation.

---

^{🦉 GitGuardian detects secrets in your source code to help developers and security teams secure the modern development process. You are seeing this because you or someone else with access to this repository has authorized GitGuardian to scan your pull request.}