Rollback drill checklist, SSE metrics wiring, RPC alert threshold, wallet support guide (#1167, #1166, #1164, #1162)

[ghost-cy829]

Closes #1167
Closes #1166
Closes #1164
Closes #1162

Four backlog issues bundled together, same repo, same wave.

#1167 - two runbooks already covered what to do during an actual rollback, but nothing existed for practicing it on a schedule to confirm it still works. Added a drill checklist following the same pattern as the existing backup-restore drill (cadence, owner, procedure, success criteria, evidence capture).

#1166 - found a real bug while digging into this: sse_connections_active was already documented and exposed on /metrics, but the increment/decrement functions were never actually called anywhere in the SSE route handlers. It's been stuck at 0 in production this whole time. Wired it up at both SSE connection points, and added a new sse_disconnects_total counter since the issue specifically asked about disconnects too, not just count - a gauge that returns to the same value after a burst of disconnects/reconnects looks unremarkable, the counter catches that. Added tests confirming both actually change on connect/disconnect and show up correctly on /metrics.

#1164 - this one turned out to be docs-only. The metrics infrastructure already tracks retry exhaustion per-operation with full labels, but the alerting rules only ever asked "did this happen at all" (rate > 0), which can't tell a single blip apart from a sustained failure. Added a proper escalation-tier threshold: 3+ exhaustions for the same operation within 15 minutes, which is a meaningfully different signal worth paging on, versus the existing rule which stays as a lower-priority warning.

#1162 - nothing like this existed. Built a 3-layer triage guide (wallet connection / RPC submission / on-chain contract) grounded in the actual code - the real 23 SplitError mappings in contract-errors.ts, the real timeout/rejection paths in soroban-transaction.ts. Tells support what's user-fixable versus what to escalate, and flags ArithmeticOverflow/AccountingDiscrepancy as always-escalate-immediately since those indicate the contract's internal accounting disagreed with itself.

Verification: ran the full backend test suite for the touched files (13 tests, all passing, including 3 new ones for #1166). tsc typecheck clean on everything I touched - confirmed via git stash that the 9 pre-existing errors elsewhere (splits.ts) exist identically on main, unrelated to this. Ran the actual markdown-link-check and prettier config CI uses - fixed formatting on the two new files I wrote, left the pre-existing repo-wide formatting failures alone (confirmed 93+ files already fail that check on main, not something this PR should try to fix wholesale). Re-verified the whole thing end to end on a completely fresh clone and reinstall after main moved mid-session, still green.

[drips-wave]

@ghost-cy829 Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits.

You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀

Learn more about application limits