fix(mcp): scope the global /mcp tool list to the caller's organization and roles

[keysersoft]

tools/list on the global /mcp endpoint returned every tool registered in the deployment to any authenticated caller.

Why

The global registry holds one entry per tool name for the whole instance, and the transport's tools/list handler is synchronous — it can neither query the database nor know which tenant is asking, so it filtered on nothing.

Impact

1. Cross-tenant disclosure. One organization's tool names, descriptions, annotations and input schemas were readable by every other organization. Reproduced by seeding a second tenant locally:

5 tools: [... , 'othertenant_confidential_report']
CROSS-ORG LEAK: ['othertenant_confidential_report']

…returned in full, including the description and input schema. Cloud currently has 433 organizations with tools.

2. Role restriction never reached the listing. A user on a role granting two of four tools saw all four; a user on the DENY_ALL "No access (SSO)" role saw everything. Syncing roles from a directory exists precisely so people stop seeing what they may not use.

Calls were never affected — tools/call resolves by name and organization and refused a mismatch — so this is a confidentiality problem, not an access one. The per-server /mcp/<serverId> endpoint already filtered correctly because it builds a server per request, which is why the gap went unnoticed.

The fix

Each registered tool gets a synthetic tool:<name> role; the controller resolves the caller's visible set asynchronously before delegating, so the synchronous filter has something to work with.

Keyed on name, not tool id: the registry keeps one entry per name across tenants, so the id belongs to whichever tenant registered first — gating on it would hide a tool from everyone else who legitimately has one by that name.

Callers with no resolvable principal (static MCP_API_KEY / MCP_BEARER_TOKEN, or explicitly enabled anonymous mode) keep the previous "everything" answer. Those are operator credentials on a single-tenant self-hosted box; narrowing them would break those deployments for no gain.

The in-handler role check is kept as a second layer, so a tool ever registered without a visibility role is still not freely callable.

Verification

Case	Before	After
Org A listing org B's tool	leaked in full	absent
No access (SSO) role	4 tools	0 tools
Role granting 2 of 4	4 tools	exactly those 2
User with no role	own org's tools	unchanged
Allowed tools/call	works	works
Per-server endpoint	correct	unchanged

3849 tests pass, plus a regression test pinning the contract — if attachVisibleTools stops running or the registration drops the visibility role, the listing silently reopens.