[Bug]: GET /api/v1/servers lists every server to a profile-pinned agent token (#1166 filter only covers legacy allowed_servers) #1682

What happened?

A token created with --profile is limited to the profile's servers on the MCP surface, but GET /api/v1/servers returns every configured server to it. The #1166 fix filters through auth.CanEnumerateServer -> AuthContext.CanAccessServer, which only consults AllowedServers. A profile-pinned token takes its scope from the profile, so the REST door does not filter it.

Metadata only (names, protocol, command, URL, non-secret env values, connection state). Secret env values are masked.

Expected behavior

A profile-pinned token sees only the profile's effective servers over REST, the same subset it gets from /mcp/all, upstream_servers list, and a legacy-scoped token. GET /api/v1/servers?profile=<name> already implements that row filter, so the fix may be to apply the token's pinned profile as the implicit profile for non-admin callers.

Steps to reproduce

1. Configure two stdio servers, a and b.
2. mcpproxy profile create p --servers a --max-tier read
3. mcpproxy token create --name t-profile --profile p and mcpproxy token create --name t-legacy --servers a --permissions read
4. curl -s -H "X-API-Key: <t-profile token>" http://127.0.0.1:8080/api/v1/servers | jq '[.data.servers[].name]' returns ["a","b"] (expected ["a"]).
5. The same call with the t-legacy token returns ["a"] (correct).
6. For comparison, upstream_servers with {"operation":"list"} over /mcp using the profile token returns 1 server (correct). Only the REST door disagrees.

Observed on a 12-server config: profile token sees 12, legacy token sees 1, MCP upstream_servers list sees 1.

MCPProxy version

v0.71.1 (personal) linux/amd64 (release binary; sha256 matches checksums.txt)

Operating system

Linux

Relevant logs

None needed.

Additional notes

• Related, closed: REST server enumeration ignores agent-token scope: /api/v1/servers and /api/v1/config list every server regardless of allowed_servers #1166 (same defect class), Add a route-table guard test so new /api/v1 GET routes cannot ship unscoped #1178 (route-table guard). I found no open issue for the profile case.
• Other REST reads may need the same check once the predicate knows about profile scope (/api/v1/servers/{id}/tools, activity). I only verified /api/v1/servers.
• /api/v1/config, /api/v1/tokens and write operations are correctly refused for agent tokens ("Agent tokens cannot ...").
• Happy to send a PR (with a test next to the REST server enumeration ignores agent-token scope: /api/v1/servers and /api/v1/config list every server regardless of allowed_servers #1166 ones) if the approach above is right.

Pre-submission checklist

• I searched existing issues and did not find a duplicate
• I ran mcpproxy doctor and reviewed the output