feat(mcp): expose .loopover.yml config recommendations as a read-only MCP tool (loopover_get_config_recommendation)

[JSONbored]

Context

GET /v1/repos/:owner/:repo/gittensor-config-recommendation (src/api/routes.ts, handler buildGittensorConfigRecommendationResponse) already exists and returns concrete, actionable recommendations for what a repo owner should add to their .loopover.yml — built from the repo's currently-active (dashboard/API-configured) behavior via buildGittensorConfigRecommendation, deliberately comparing against the raw DB settings rather than the yml-merged view so the recommendation never compares itself against itself once an override exists (see the route handler's own #2912 comment). It sits behind the same generic /v1/repos/* API-token auth tier as every other already-MCP-exposed repo-context tool (requiresApiToken + authenticateRequestIdentity in the global middleware in createApp()) — no additional session-only or internal-only gate layered on top, unlike a few sibling /v1/repos/* routes that do add one.

This directly serves the product's own "config-as-code" mandate — recommending concrete .loopover.yml additions is exactly the kind of thing an MCP-connected repo-owner or maintainer agent should be able to ask for. It's also explicitly named as a recommended capability for the repo-owner-intake MCP client profile documented in packages/loopover-mcp/bin/loopover-mcp.js (AGENT_PROFILES["repo-owner-intake"]), whose stated purpose is "Review registration readiness, focus manifests, docs/onboarding gaps, and manual setup actions" — yet that profile's recommendedTools list currently only has loopover_get_repo_context and loopover_get_issue_quality; there is no tool at all for the config-recommendation half of that purpose.

The response is already reused as a building block internally (buildSelfDogfoodRegistrationPackResponse calls it directly), confirming it's a stable, well-formed, individually-useful payload — it just has no MCP tool wrapping it.

Requirements

• Add a new tool loopover_get_config_recommendation to src/mcp/server.ts, following the same class/method pattern as the existing repo-scoped GET tools (e.g. loopover_get_label_audit, which similarly wraps a /v1/repos/:owner/:repo/* read-only route).
• Input schema: ownerRepoShape (the same { owner, repo } shape already used by loopover_get_repo_context, loopover_get_label_audit, loopover_get_burden_forecast, etc.).
• Implementation: call the existing buildGittensorConfigRecommendationResponse(env, fullName) function directly (it's already exported/importable from src/api/routes.ts, or extract it to a shared location if the server class doesn't already import route-layer helpers — follow whatever pattern the class uses for the other repo-context-family tools) rather than making an internal HTTP round-trip to the route. Do not reimplement buildGittensorConfigRecommendation's logic.
• Description text: state plainly that this returns recommended .loopover.yml additions derived from the repo's live, currently-active configured behavior (not a yml-merged view), and that it is advisory-only (no write).
• Add an output schema following the file's outputSchema convention for structured tool responses (see #291).

Deliverables

• loopover_get_config_recommendation tool registration in src/mcp/server.ts
• Unit/integration test(s) covering: a repo with a clean recommendation (no gaps), a repo with at least one recommended addition, and the not-found/unregistered-repo case
• Registration in the repo-owner-intake profile's recommendedTools list in packages/loopover-mcp/bin/loopover-mcp.js (AGENT_PROFILES), since that profile's stated purpose already names this capability but has no tool for it

Test Coverage Requirements

99%+ Codecov patch coverage on every changed line and branch in src/mcp/server.ts for the new tool handler, including the has-recommendations and no-recommendations branches.

Expected Outcome

An MCP client (e.g. under the repo-owner-intake profile) can call loopover_get_config_recommendation({ owner, repo }) and get the same .loopover.yml recommendation payload GET /v1/repos/:owner/:repo/gittensor-config-recommendation already returns, without needing direct REST/API access.

Links & Resources

• Precedent tool to model from: loopover_get_label_audit in src/mcp/server.ts (same repo-scoped, advisory-only, ownerRepoShape GET-wrapper pattern)
• Underlying capability: buildGittensorConfigRecommendationResponse / buildGittensorConfigRecommendation in src/api/routes.ts, route GET /v1/repos/:owner/:repo/gittensor-config-recommendation
• Related history: feat(registration): add Gittensory registration readiness and config recommendation #38 (built the underlying config-recommendation feature), [Bug]: Self-dogfood pack lane strategy contradicts its own config recommendation #442 (a past bug in its lane-strategy logic — confirms the feature is real and already load-bearing), feat(mcp): expose the repo label-policy audit via gittensory_get_label_audit #1602/feat(mcp-cli): add stdio tool gittensory_get_label_audit (proxy the hosted tool) #2229 (the label-audit MCP tool this issue's pattern follows)

[linear-code]

JSO-4007