feat: implement per-user token auth for Vault (#18)

[jh-lee-cryptolab]

Summary

• Per-user token management via runevault CLI (issue, revoke, list)
• Role-based access control with CRUD operations (admin/agent defaults + custom roles)
• In-memory token/role store with async YAML persistence (vault-tokens.yml, vault-roles.yml)
• Admin HTTP API on container-internal unix socket (no admin token — SSH + docker group + container isolation)
• Per-user rate limiting, top_k enforcement, scope checks, token expiry
• Per-user monitoring labels in Prometheus metrics
• Backward compatibility: legacy VAULT_TOKENS env var with deprecation warning
• Cloud deployments (AWS/GCP/OCI): migrate VAULT_TOKENS → VAULT_TEAM_SECRET, add config volumes and runevault alias

Design decisions

Metadata DEK: per-agent → single team key

Previously, metadata DEKs were issued per agent_id. With per-user tokens, every user with decrypt_metadata scope can decrypt metadata — so per-agent DEKs provide no meaningful isolation. If any single DEK is compromised, the attacker gains access to the same data that all other DEKs protect. Switched to a single team_secret-based metadata key to simplify key management without reducing effective security.

Test plan

• pytest tests/unit/test_token_store.py — token lifecycle, role CRUD, rate limiting, persistence
• pytest tests/unit/test_admin_server.py — admin HTTP API over unix socket
• pytest tests/unit/test_auth.py — token validation, scope enforcement
• Docker build + runevault token issue/list/revoke smoke test
• Verify gRPC error codes (UNAUTHENTICATED, RESOURCE_EXHAUSTED, INVALID_ARGUMENT)

Closes #18

[jh-lee-cryptolab]

Additional changes planned for metadata DEK architecture:

Motivation: The current design derives a single shared DEK from VAULT_TEAM_SECRET and distributes it to all agents. If any agent's DEK is compromised, all team metadata encrypted with that key is exposed, and there is no way to rotate the key for the affected agent without impacting every other agent.

1. Use VAULT_TEAM_SECRET as the master secret and HKDF for per-user DEK derivation.
   Each agent's DEK will be derived via HKDF using the team secret as input key material and a per-user identifier as salt/info: agent_id = SHA256(token)[:32], agent_dek = HKDF-SHA256(ikm=team_secret, info=agent_id). This ensures:

   • Each member receives a unique DEK tied to their token.
   • Vault can still decrypt any member's metadata using team_secret + the agent_id stored in the envelope {"a": ..., "c": ...}.
   • Token rotation automatically rotates the DEK — revoking a compromised token invalidates the associated DEK for future writes, while existing data remains decryptable via the envelope's agent_id.

2. Remove dependency on pyenvector's MetadataKey.json for DEK derivation.
   Currently, Vault loads MetadataKey.json via get_key_stream() and uses it as the HMAC master key for per-agent DEK derivation. However, enVector Cloud's built-in metadata encryption is disabled (metadata_encryption=False on index creation), and the key file is only generated as a side effect of pyenvector's default KeyGenerator behavior (metadata_encryption defaults to True). This key is being repurposed outside its original intent. Item 1 above replaces this with Vault's own master secret.