[Feature] Resolver committee onboarding process #201

Summary

docs/src/DEPLOYMENT.md already documents the on-chain mechanics of managing the resolver committee: update_resolvers (admin emergency override) and propose_rotation/vote_rotation (self-service majority rotation), plus set_admin now that admin rotation exists. None of that says anything about the human, off-chain side: who actually becomes a resolver, how their signing key is generated and secured, what happens when one needs to be replaced for a reason other than "the admin decided to," and what a resolver is actually expected to do when a dispute lands in front of them.

DEPLOYMENT.md's current resolver guidance is limited to "pick people who'll actually be reachable" and a testnet stopgap ("resolver1/resolver2/resolver3... no real-world accountability behind them yet. Revisit before treating this instance's dispute history as trustworthy long-term"), an acknowledged gap, not a real process.

Scope

• Document the actual onboarding process for a new resolver: identity/selection criteria (who is qualified to judge a dispute for this deployment's specific domain), key generation and custody (hardware wallet, multisig, or plain key, and why), and what commitments a resolver is expected to make (response time, conflict-of-interest disclosure given [Bug] resolve doesn't prevent a resolver from voting on their own case #165's guard against voting on their own case).
• Document the offboarding/replacement process in practice, not just the on-chain call: what triggers a replacement (inactivity, compromised key, conflict of interest, resignation), who initiates it, and how the self-service propose_rotation path versus the admin update_resolvers override should each actually be used operationally.
• Should live in docs/src/DEPLOYMENT.md alongside the existing rotation mechanics, or a new dedicated doc if the scope grows large enough to warrant one.

Proposed approach

Not prescribed. This is process documentation, not a contract change, the on-chain primitives (update_resolvers, propose_rotation, vote_rotation, set_admin) already exist and are already documented; this issue is specifically about the governance process wrapped around using them for a real deployment, not new code.