feat: migrate mcp-server and virtual-server endpoints to v1 API paths

[marekdano]

Closes #85

Summary

• Migrate MCP-server and virtual-server CRUD calls from the legacy /gateways and /servers API paths to the versioned /v1/mcp-servers and /v1/virtual-servers paths
• Update corresponding unit tests, e2e specs, and MSW mock handlers to match the new paths
• Leave the user-facing MCP connection URL (utils.ts getVirtualServerEndpoint) unchanged, since it reflects protocol data, not the admin API

Details

This is a mechanical rename with no behavior changes. The new versioned paths are already live on the backend (mounted alongside the legacy paths since mcp-context-forge commit f9af132ee), so this is a forward-compatible migration ahead of the legacy paths being deprecated.

Test plan

• All 494 tests across the 15 affected files pass
• Verified no remaining references to the old /gateways or /servers API paths in src/ or e2e/
• Confirmed the new /v1/mcp-servers and /v1/virtual-servers routes are mounted on the backend

[a-effort]

Verified on 85-migrate-v1-endpoints: tsc clean, full vitest suite green (3278 passed).

• mcpgateway/api/v1/__init__.py:374-375 mounts the same gateway_router and server_router objects at /v1/mcp-servers and /v1/virtual-servers that the legacy prefixes use, so response shapes, query params and pagination are identical. GET "", /{id}, PUT, DELETE and /{id}/state all exist under both.
• Token scoping resolves the aliases back to /gateways and /servers before matching (middleware/token_scoping.py:444,466 via utils/paths.py:52-53), so scoped tokens are unaffected. This was my main worry, since unmapped paths default-deny.
• No legacy literal is left in src except getVirtualServerEndpoint, as described.

Potential blocker: docker-compose.e2e.yml:37 pins a backend that predates the aliases

ghcr.io/ibm/mcp-context-forge:v1.0.8 was cut 2026-08-18. f9af132ee landed 2026-08-24 and first ships in v1.0.9 (2026-09-01). So npm run e2e:docker now runs the migrated UI against a backend where /v1/mcp-servers and /v1/virtual-servers do not exist.

e2e/tools.spec.ts and e2e/resources.spec.ts fetch /v1/mcp-servers?limit=0&include_pagination=true (Tools.tsx:206, Resources.tsx:253). Against v1.0.8 that 404s and the cards fall back to raw IDs instead of server names. Bumping the pin to v1.0.9 or later covers it.

[gcgoncalves]

AI review:

Must fix: e2e/quick-add-server.spec.ts (e2e/quick-add-server.spec.ts) still intercepts */gateways? instead of **/v1/mcp-servers?*. The PR description explicitly claims "no remaining references to the old paths in e2e/" — this contradicts that. When the legacy endpoint is eventually removed from the backend, this test will stop intercepting the correct requests.
Pre-existing: validateServerId uses a strict regex (/^[a-zA-Z0-9_-]+$/) that rejects slash-containing IDs, while virtualServers.ts correctly uses encodeURIComponent for the same purpose. Not introduced by this PR but more visible now.
ServersResponse.gateways type field name is legacy; the JSON key is preserved by the backend, but it's a future rename candidate. One file fix (quick-add-server.spec.ts) and this is approvable.