admin: give better previews of key blocking actions

Adding a key to the blockedKeys table is a big action that is both difficult to reverse and can have far-reaching consequences if that key is used by many other certificates, which will then all be revoked by bad-key-revoker. However, adding a key to the blockedKeys table is also an opaque action, since the consequences of it are downstream: bad-key-revoker runs asynchronously.

It would be good for the admin tool to surface potential large-impact key blocks before they're written to the database. This can warn the operator up-front of potential downstream consequences before any real actions are taken.

Note that the admin tool has two codepaths which can block keys: the block-key subcommand, and the revoke-cert subcommand when used with the keyCompromise revocation reason. In the latter case, it's not the admin tool which directly blocks the key, but rather the RA while handling the AdministrativelyRevokeCertificate RPC. These disparate code paths may deserve some unification and some extra safeguards (e.g. a mandatory --block or --no-block flag to the revoke-cert subcommand) as part of this work.

Trace both admin entry points: the block-key subcommand and revoke-cert with the keyCompromise reason, then follow the AdministrativelyRevokeCertificate RPC into the RA. Check how blockedKeys entries reach bad-key-revoker and define the preview and safeguard behavior before database writes. Done means both paths surface potential impact clearly and require an explicit operator choice.