fix(vault): inject tokens for A2A-backed tools invoked via MCP

[chengwudi1]

📋 Summary

Fixes #6394 — the Vault plugin did not inject vault tokens when an A2A agent wrapped as an MCP tool was invoked
through the MCP protocol (tools/call). Token injection only worked via the direct /a2a/{name}/invoke path
(agent_pre_invoke).

Root cause: tool_pre_invoke resolved the system tag only from the gateway metadata. A2A-backed tools carry an
a2a_agent_id annotation (and replicate the agent's tags, e.g. system:<host>), but that metadata was never
consulted.

🔧 Changes

• plugins/vault/vault_plugin.py: in tool_pre_invoke, when the tool metadata carries the a2a_agent_id annotation,
  the system/auth-header tags are resolved from the tool metadata (which carries the agent's tags) instead of the
  gateway metadata. Non-A2A tools keep the existing gateway-metadata resolution behavior.

✅ Tests

Added 2 unit tests in tests/unit/.../test_vault_plugin.py:

• test_a2a_backed_tool_injects_token_from_tool_metadata — A2A-backed tool with a system: tag on the tool metadata
  gets the Bearer token injected (fails on the unpatched code).
• test_regular_tool_ignores_tool_metadata — non-A2A tools still resolve from the gateway metadata only (regression
  guard).

All 39 unit tests pass; ruff check and ruff format clean.

[jonpspri]

Closing in favour of #6395, which addresses the same Vault plugin A2A token injection gap with a significantly more complete implementation: full e2e test suite, defence-in-depth header stripping, A2A metadata loading, and it is already approved. This PR's focused plugin-only fix is superseded by #6395.