feat(mcp): add a loopover_get_maintainer_lane CLI mirror

[jeffrey701]

Closes #6739

Problem

The MCP tool loopover_get_maintainer_lane (src/mcp/server.ts:1863) returns data that already ships as the .maintainerLane field of GET /v1/repos/:owner/:repo/intelligence. The CLI already proxies that exact same endpoint for the sibling field — loopover_get_label_audit picks out .labelAudit, and loopover_get_burden_forecast picks out its own field — but maintainerLane, which sits right beside them in the same buildRepoIntelligenceResponse payload, had no CLI extraction at all.

Fix

Add registerStdioTool("loopover_get_maintainer_lane", { inputSchema: ownerRepoShape }, ...) to loopover-mcp.js, copying loopover_get_label_audit's implementation byte-for-byte and returning { repoFullName, generatedAt, maintainerLane: intelligence?.maintainerLane ?? null }, plus its registry entry (category: "maintainer") so stdioToolDescription resolves. No new route, no new fetch shape — it reuses the GET the sibling tools already make.

Tests

New test/unit/mcp-cli-maintainer-lane.test.ts (mirrors mcp-cli-label-audit.test.ts):

1. the tool is registered in the stdio server's tool list;
2. it proxies owner/repo to /v1/repos/:owner/:repo/intelligence via apiGet and returns the maintainer lane (public-safety regex asserted, as the sibling does);
3. parity with the mirrored surface — it hits the same /intelligence route loopover_get_label_audit uses, agrees with it on repoFullName/generatedAt for identical input, and each tool surfaces only its own slice (maintainerLane vs labelAudit).

mcp-tool-rename-aliases.test.ts's two hard-coded tool-count assertions are updated 67 → 68 (the list is exact-count asserted in both the live server and loopover-mcp tools --json).

Validation

• npx vitest run test/unit/mcp-cli-maintainer-lane.test.ts → 3/3 pass
• npx vitest run test/unit/mcp-tool-rename-aliases.test.ts → 10/10 pass (68-tool count on both surfaces)
• Full MCP net (test/unit/mcp-*.test.ts) → zero net-new failures: the failing set is byte-identical to the pristine baseline (25 pre-existing, Windows-only: npm-registry/telemetry/file-mode cases), with my new file adding 3 passes.
• npm run typecheck → clean (0 errors); npm run build:mcp → passes; npm run command-reference:check → passes.
• Scope: 1 source file + 1 new test + 1 count update.

[superagent-security]

Superagent didn't find any vulnerabilities or security issues in this PR.

[jeffrey701]

Closing this immediately — it was built from a stale checkout and its whole-file blob would revert 158 lines of already-merged work (loopover_simulate_open_pr_pressure #6915, loopover_build_results_payload #6904, loopover_intake_idea #6916) and roll the tool-count assertion back from 70 to 68. That is entirely my mistake, not a review dodge.

Re-opening a clean version rebased on current main shortly. Apologies for the noise.

[codecov]

❌ 2 Tests Failed:

Tests completed	Failed	Passed	Skipped
2429	2	2427	0

View the top 2 failed test(s) by shortest run time

test/unit/mcp-cli-results-payload-tool.test.ts > loopover_build_results_payload stdio mirror (#6752) > matches the pure composer for every input shape — offline, with no API reachable

Stack Traces | 1.02s run time

AssertionError: {"repoFullName":"acme/widgets","prNumber":42,"title":"Opened","status":"open"}: expected true to be falsy

- Expected
+ Received

- false
+ true

 ❯ test/unit/mcp-cli-results-payload-tool.test.ts:62:52

test/unit/mcp-cli-results-payload-tool.test.ts > loopover_build_results_payload stdio mirror (#6752) > registers the tool alongside its same-tier check_slop_risk sibling

Stack Traces | 1.25s run time

AssertionError: expected [ 'loopover_get_repo_context', …(67) ] to include 'loopover_build_results_payload'
 ❯ test/unit/mcp-cli-results-payload-tool.test.ts:39:19

To view more test analytics, go to the Test Analytics Dashboard
_{📋 Got 3 mins? Take this short survey to help us improve Test Analytics.}