feat(mcp): pipeline read tools

[andypalmi]

Summary

Adds Phase 1 read-only MCP tools for DevOps pipelines.

Tool file: forge/ee/lib/mcp/tools/pipelines.js

Tools added:

• platform_list_pipelines - lists a team's or an application's pipelines; takes an optional teamId or applicationId. With applicationId it calls GET /api/v1/applications/:applicationId/pipelines, otherwise with teamId it calls GET /api/v1/teams/:teamId/pipelines.
• platform_get_pipeline_stage - GET /api/v1/pipelines/:pipelineId/stages/:stageId

Both tools carry readOnlyHint: true and destructiveHint: false.

Permissions:
#8185 removed the hardcoded user:expert-mcp scope allow-list, so expert MCP tokens now inherit the user's permissions gated by team role and no allow-list entries are needed.

Consolidation notes

The team and application pipeline list tools are combined into a single platform_list_pipelines taking either teamId or applicationId; both routes are unpaginated and share the same role, so one tool with an id argument is simpler for the agent.

Closes #7696

Test plan

• eslint
• mocha unit tests

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 75.96%. Comparing base (d3419bb) to head (2cc6230).

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #7715      +/-   ##
==========================================
+ Coverage   75.94%   75.96%   +0.01%     
==========================================
  Files         445      446       +1     
  Lines       23990    24003      +13     
  Branches     6404     6406       +2     
==========================================
+ Hits        18220    18233      +13     
  Misses       5770     5770              

Flag	Coverage Δ
backend	75.96% <100.00%> (+0.01%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[andypalmi]

Testing results of new tools

Local platform context these calls ran against:

• One application (Andrea's Application) with 11 hosted instances, no pipelines to start with.
• A pipeline was seeded (MCP Verify Pipeline) with two chained stages: Dev (targets a hosted instance, create_snapshot action) then Staging (targets a hosted instance, use_latest_snapshot action).

This PR adds 2 read tools to a new pipelines.js; both are exercised below. Payloads show the shape of what came back, with hashids and instance UUIDs redacted as PIPELINE_ID STAGE_ID APP_ID INSTANCE_ID; structural values (counts, actions, stage names) are verbatim.

platform_list_pipelines

Lists a team's or a single application's pipelines. The handler requires exactly one of teamId or applicationId and returns a 400 otherwise (both stay optional strings so the function schema keeps no top-level union). Each pipeline is returned with its ordered stages and their instance targets.

Case	Input params	Verdict	Returned payload (overview, redacted)
by teamId	{teamId}	PASS	{count:1, pipelines:[{id:PIPELINE_ID, name, stages:[Dev(create_snapshot)->Staging(use_latest_snapshot)], application:{id:APP_ID,name}}]}
by applicationId	{applicationId}	PASS	same pipeline record; stages array length 2, in Dev->Staging order (no application block on the application-scoped route)
neither	{}	PASS	{content:"Provide exactly one of teamId or applicationId.", code:400, isError:true}
both	{teamId,applicationId}	PASS	{content:"Provide exactly one of teamId or applicationId.", code:400, isError:true}
nonexistent teamId	{teamId:"zzzzzzzzzz"}	PASS	{content:{code:not_found}, code:404, isError:true}
nonexistent applicationId	{applicationId:"zzzzzzzzzz"}	PASS	{content:{code:not_found}, code:404, isError:true}

platform_get_pipeline_stage

Fetches one stage within a pipeline, including its target (hosted instance here) and snapshot action. Requires both pipelineId and stageId.

Case	Input params	Verdict	Returned payload (overview, redacted)
valid (Dev stage)	{pipelineId,stageId}	PASS	{id:STAGE_ID, name:"Dev", action:"create_snapshot", deployToDevices:false, instances:[{id:INSTANCE_ID,name,url,...}], NextStageId:STAGE_ID}
valid (Staging stage)	{pipelineId,stageId}	PASS	{name:"Staging", action:"use_latest_snapshot", instances:[one], NextStageId:null} (tail of the chain)
nonexistent stageId	{pipelineId, stageId:"zzzzzzzzzz"}	PASS	{content:{code:not_found}, code:404, isError:true}
nonexistent pipelineId	{pipelineId:"zzzzzzzzzz", stageId}	PASS	{content:{code:not_found}, code:404, isError:true}
stage from another pipeline	{pipelineId, stageId:<other pipeline's stage>}	PASS	{content:{code:not_found}, code:404, isError:true} (route rejects a stage not belonging to the given pipeline)

Conclusion

Both new tools in pipelines.js are verified against their descriptions, including the exactly-one-owner rule and both owner paths (team:pipeline:list, application:pipeline:list) on platform_list_pipelines, the ordered-stage output, the stage lookup with its instance target and snapshot action (pipeline:read), and the not-found paths including a stage that belongs to a different pipeline.