secrets: fail loudly on a bad 1Password token instead of a LiteLLM prompt

A bad token paste (or a vault/item that did not match the login-name
default) used to surface only as mcp-config asking for a LiteLLM key,
hiding that every vault key was missing. Now:

- the token is verified with `op whoami` and re-prompted on a bad paste
- vault and item are validated, auto-picked when the token sees only one,
  and otherwise prompted with the list it can see
- bootstrap skips mcp-config and hermes, with an error naming the cause,
  when no LITELLM_KEY came from the vault

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

README.md

@@ -59,8 +59,12 @@ Already have a clone? Just run it directly:
   sources, so opening a shell never calls `op`. One vault per user and one
   item in it, both named after your login by default; each field's label is
   the variable name (`GITEA_KEY`, `LITELLM_KEY`, `PROXMOX_TOKEN_SECRET`, …).
-  The first run prompts for the service-account token (and vault/item), and
-  keeps them in `~/.config/dotfiles/op.env` (0600, not loaded into shells).
+  The first run prompts for the service-account token and checks it with
+  1Password straight away, re-prompting on a bad paste. It then picks the vault
+  and item: the only one the token can see, or a prompt that lists them. It keeps
+  all three in `~/.config/dotfiles/op.env` (0600, not loaded into shells). If
+  that fails, bootstrap skips mcp-config/ and hermes/ with an error rather
+  than asking for the LiteLLM key by hand.
   Runs after `bin/` (needs `op` and `jq`); bootstrap loads the result so later
   modules get the keys without prompting. Day to day: `opr NAME` reads a
   field, `opc NAME [VALUE]` creates or updates one (prompts, hidden, without