[Refactor] Use the MCP SDK for native GitLab tools

[roomote-roomote]

​Created by Roomote. View the task or mention @roomote-roomote for follow-up asks.

What changed

• Register the twelve bounded GitLab tools through the MCP SDK with their existing strict schemas and annotations.
• Replace the hand-written JSON-RPC initialization, discovery, dispatch, and response framing with the standard web streamable HTTP transport.
• Separate the thin Hono mount, tool registration, schemas, and bounded GitLab provider operations.
• Adapt the focused contract tests to exercise standard MCP initialization, metadata, capabilities, and tool error results.

Why this change was made

The native GitLab integration introduced in #2382 duplicated protocol behavior already owned by the MCP SDK. Keeping a second local protocol stack increased drift risk and mixed transport concerns with provider authorization and operations.

Impact

There is no intended user-facing behavior change. GitLab tools retain their repository and OAuth boundaries, operation timeout, pagination and file limits, ownership checks, credential suppression, redirect refusal, request size limit, and output fence while protocol semantics now follow the same SDK-backed pattern as neighboring integrations.

[roomote-community]

1 issue outstanding. See task

• apps/api/src/handlers/mcp/gitlab/operations.ts:89 can exceed the 1 MiB response limit when a client uses a long JSON-RPC request ID.

_{Reviewed dce2459}

[roomote-community]

safeToolResult calculates the response ceiling with id: null, but the streamable transport serializes the client-supplied JSON-RPC ID into the actual response. A valid ~60 KiB string ID within the 64 KiB request limit plus a result that reaches this 1 MiB check produces a response over 1.1 MiB. Preserve the output fence by accounting for the real ID or reserving the maximum possible request-ID overhead.