Prepare docs for signer-based validator verification once the BLS flow ships.

[johnnymatthews]

This one should wait until the feature is live, so file it as blocked. A team survey of validator operators in Discord lays out what's coming: registering as a Generator will need one signature from the validator key, at sign-up only. The signer signs a 32-byte digest covering the validator public key, the nominated address, the network, and the timestamp, and the Shinzo verifier checks control (you hold the key) and liveness (the validator has activated, hasn't been slashed, and has no exit queued, read from a finalized state on the verifier's own beacon node).

A user in Discord also asked whether non-custodial validators can register using the validator's BLS signing key, without control of the withdrawal key. The team said that's the direction, but it isn't live yet, and they didn't want to imply otherwise.

When it ships, the docs work is:

• Signer requirements per setup: Web3Signer (default port 9000, the /signer/v1/get_pubkeys endpoint, --http-listen-port), Commit-Boost's signer module (default port 20000, /status, the port under [signer] in cb-config.toml), Dirk, and keystore files on the validator machine with no separate signing service.
• The restart cost. Signers decrypt every keystore at startup, and while a signer restarts, none of the validators behind it can attest or propose. Operators will want to plan that window, and the docs should say so up front.
• The setup questions the survey had to ask: does the signer hold the keys itself or front a Dirk, which modules are registered in it, and is cb-config.toml managed by hand or with commit-boost init. Those being survey questions is the signal they'll be docs questions.
• Updates to the register page and the assertion reference, which currently describe the withdrawal-address flow (admin-key approved on testnet, withdrawal-key signature in the planned contract flow). Clarifies current and future assertion flows. #433 and Clarify assertion flow: remove references to non-live on-chain validator checks #424 have been keeping the current-versus-future split honest there. This continues that work.

Related: #314 covered the withdrawal-key security story and #401 (closed) covered Generator placement.