#2627 access token mint --server: server demands --vault, no client version has that flag

Description

Minting a server access token via --server (in a repo with multiple vaults configured, e.g. mircloud-colo and _token-secrets) fails with a server-side error that names a client CLI flag which does not exist in any client version checked.

Steps to reproduce

1. Repo/server has two vaults configured: mircloud-colo and _token-secrets.
2. Run: swamp access token mint --principal user:
   --server https:// --token "$TOK"
3. Server responds: Error: Server reported access_token_mint_failed: Multiple vaults are configured (mircloud-colo, _token-secrets). Pass --vault to choose one.
4. Retry with --vault _token-secrets (as instructed): Error: 'Unknown option "--vault". Did you mean option "--help"?'

Confirmed via swamp help access token mint (structured JSON schema) on two separate client installs -- one at 20260923.231117.0-sha.ad0aa46d, one freshly updated to the latest available via the standard installer -- neither lists a --vault option for access token mint, nor is there a documented env var for it (checked SWAMP_* env vars listed against every option in the help output). The access command group's global options don't include it either.

Environment

• Client version (session confirmed): swamp 20260923.231117.0-sha.ad0aa46d
• Server: swamp serve, --auth-mode token, multiple vaults configured (mircloud-colo, _token-secrets)

Impact

A server access token cannot be minted via --server at all when the target repo has more than one vault configured -- the only remote minting path is blocked, with no working client-side flag to satisfy the server's own error message. Local minting (--repo-dir against a pod-local/mounted repo clone) is unaffected, since it apparently doesn't hit the same vault-selection ambiguity, but that path requires filesystem access most callers (an end-user self-minting their own personal token) don't have.