docs: mainnet operational runbook (admin custody, launch sequence, incident escalation)

[Iker2522]

Summary

DEPLOYMENT.md already covers parameter selection (V1_MAINNET_PARAMETERS.md, #190) and the on-chain admin/resolver mechanics. RESOLVER_GOVERNANCE.md already covers resolver key custody, onboarding, and offboarding in depth. Neither covers the admin role's own key custody, a concrete go/no-go launch procedure, or incident escalation specifics — this PR adds MAINNET_RUNBOOK.md, covering exactly that gap, not a rewrite of either existing document.

Explicitly framed throughout (and especially at the top) as prep work written ahead of the audit clearing, per SECURITY.md's hard blocker — useful to have ready, not a signal mainnet deployment is authorized now.

What changed

New docs/src/MAINNET_RUNBOOK.md: admin key custody (including a finding from reading the contract directly — propose_admin requires the current admin's signature, so there's no on-chain recovery from a genuinely lost/destroyed admin key), an 11-step go/no-go launch sequence, and an incident decision tree (set_paused vs. resolver rotation vs. reclaim_stalled_dispute vs. doing nothing).
Fixed a real, unrelated staleness bug found while researching this: DEPLOYMENT.md's "Rotating the admin key" section still documented the old single-step set_admin, which no longer exists — the contract now uses the two-step propose_admin/accept_admin flow CONTRACT.md already documents correctly. Corrected it so the new runbook doesn't contradict it.

Test plan

Read the actual propose_admin/accept_admin/set_paused/set_stall_timeout/reclaim_stalled_dispute implementations in contracts/tholos/src/lib.rs directly to ground the guidance in real behavior, not assumptions
Verified all 10 internal anchored links against the actual compiled mdbook HTML output (not assumed slug format) — one (reclaim_stalled_dispute) points to the source doc comment instead of CONTRACT.md, since that function isn't documented there yet (pre-existing gap, out of scope here)
mdbook build docs (v0.4.48, same as CI) builds cleanly
No contract or test changes — docs only

Closes #205

[collinsezedike]

Good structure and correctly scoped against DEPLOYMENT.md/RESOLVER_GOVERNANCE.md. Two factual accuracy issues, both inline.

[collinsezedike]

These read-only calls don't exist. contracts/tholos/src/lib.rs's only public read entrypoint is get_assertion_state(id), which returns an Assertion struct with no admin, challenge_window, finalize_reward_bps, or resolvers-at-rest fields (resolvers stays empty until a dispute happens). There's no get_admin, get_resolvers, get_bond_amount, or get_config. An operator following this step during an actual launch has no on-chain way to do the verification as written.

[collinsezedike]

finalize_reward_bps has no admin setter. Grepping contracts/tholos/src/lib.rs shows only three admin setters, set_paused, set_bond_amount, set_stall_timeout, and finalize_reward_bps is written once, inside initialize. It's permanently fixed at deployment, same as challenge_window_secs and the resolver committee size. Please correct this so an operator doesn't treat getting it right pre-launch as less critical than it is.

[collinsezedike]

Both prior findings are fixed, and the verification step rewrite is genuinely better than what was there before. One new issue introduced by that same rewrite, inline.

[collinsezedike]

This says only bond_amount has an admin setter while listing resolver committee in the same sentence, but the resolver committee is also changeable post-deployment via the admin's update_resolvers call, which Part 1 of this same document already lists as an admin lever. An operator reading this step in isolation could conclude the committee is permanently fixed like challenge_window_secs and finalize_reward_bps, when it isn't. Please carve resolver committee out of that sentence, or note update_resolvers alongside set_bond_amount.