#121 [High] Add a secret-rotation runbook and expiry check for long-lived credentials

[james2177]

Description: Issue #22 introduces a pluggable secrets provider for SOROBAN_SIGNING_KEY, but even with a pluggable provider, nothing documents or automates rotating that key (or other long-lived secrets referenced across .env.example/.env.mainnet.example/.env.testnet.example) on a schedule, nor detects when a secret has silently gone stale past its intended rotation window. Add a rotation runbook plus an automated staleness check.

Problem Statement & Context: SOROBAN_SIGNING_KEY signs real on-chain transactions (src/soroban/signer.service.ts, src/soroban/stellar-tx.service.ts) — a compromised, never-rotated key is a standing risk with no expiry-based mitigation once issue #22's provider abstraction exists but rotation itself is never actually exercised. This closes the gap between "secrets can technically be rotated" (the provider abstraction) and "secrets actually get rotated" (an enforced process).

Scope & Acceptance Criteria:

• Add a runbook (alongside the existing RUNBOOK_BACKUP_RESTORE.md pattern, e.g. RUNBOOK_SECRET_ROTATION.md) documenting the rotation procedure for SOROBAN_SIGNING_KEY and any other long-lived secrets identified across the .env.*.example files, built on top of the pluggable provider from issue Replace in-memory intent creation with on-chain registration #22.
• Add an automated check (a scheduled CI job or a lightweight monitoring check) that flags when a secret's last-known-rotation date exceeds a configured threshold — this requires the secrets provider to expose or record a rotation timestamp, coordinate with issue Replace in-memory intent creation with on-chain registration #22's interface design.
• Out of scope: implementing automatic, unattended key rotation itself (auto-generating and swapping a live signing key with no human in the loop) — that's a much larger, higher-risk change; this issue delivers the documented manual procedure plus staleness detection only.

Implementation Guidelines:

1. Key files: src/soroban/signer.service.ts, src/config/env.validation.ts, .env.example, .env.mainnet.example, .env.testnet.example, RUNBOOK_BACKUP_RESTORE.md (as the structural template for the new runbook).
2. Coordinate directly with issue Replace in-memory intent creation with on-chain registration #22's secrets-provider interface design — the staleness check needs the provider to expose rotation metadata, so sequence or pair this work accordingly rather than designing it in isolation.
3. Explicitly enumerate every long-lived secret in scope (don't limit to SOROBAN_SIGNING_KEY alone) by auditing env.validation.ts and the .env.*.example files for anything that looks like a credential rather than a config toggle.
4. Testing: the staleness-check mechanism needs a test simulating an overdue rotation and confirming it actually raises an alert/fails the check; the runbook itself should be validated by a dry-run rotation against a testnet key, documented as evidence.

Definition of Done:

• Runbook written, staleness-check mechanism implemented and tested, dry-run rotation evidence attached.
• Acceptance criteria met.
• PR passes CI with test output.
• Reviewed and approved.

Resources: src/soroban/signer.service.ts, src/config/env.validation.ts, .env.mainnet.example, .env.testnet.example, RUNBOOK_BACKUP_RESTORE.md

Complexity: High (200 points)