feat(mcp): application read tools

[andypalmi]

Summary

Phase 1 read-only MCP tools for the application resource, added to forge/ee/lib/mcp/tools/applications.js:

• platform_list_application_snapshots - GET /applications/:applicationId/snapshots
• platform_list_team_instance_statuses - GET /teams/:teamId/applications/status

This PR also extends the already-shipped platform_get_application_audit_log tool with an includeChildren argument.

Each tool describes the application resource, so all are filed with the existing application tools, following the one-file-per-resource convention. platform_list_team_instance_statuses returns the applications in a team with the live status of their instances and devices.

All tools are annotated readOnlyHint: true, 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.

Closes #7690

Consolidation notes

• The three per-application instance listers (platform_get_application_hosted_instances, platform_get_application_remote_instances, platform_get_application_instances_status) are not added, because the unified platform_list_hosted_instances and platform_list_remote_instances tools already cover per-application listing via their applicationId argument, and live status via includeLiveStatus on platform_list_hosted_instances.
• platform_get_application_audit_log gains an includeChildren argument to pull in descendant entries within the chosen scope.

Test plan

• eslint on changed files passes with no errors
• mocha unit tests pass

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 76.04%. Comparing base (d3419bb) to head (8bf989e).

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #7716      +/-   ##
==========================================
+ Coverage   75.94%   76.04%   +0.09%     
==========================================
  Files         445      445              
  Lines       23990    23988       -2     
  Branches     6404     6398       -6     
==========================================
+ Hits        18220    18241      +21     
+ Misses       5770     5747      -23     

Flag	Coverage Δ
backend	76.04% <100.00%> (+0.09%)	⬆️

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/edited tools

Local platform context these calls ran against:

• One team with a single application holding 11 hosted instances (all running) and no application-assigned devices.
• The application has 70 snapshots across its instances, and an audit log with entries at both application scope and the wider project scope.

This PR adds 2 read tools to applications.js and extends platform_get_application_audit_log; all 3 new/edited tools are exercised below. Payloads show the shape of what came back, with hashids and instance UUIDs redacted as APP_ID SNAPSHOT_ID INSTANCE_ID; structural values (counts, states, events) are verbatim.

platform_list_application_snapshots

Lists the snapshots belonging to an application. Honors limit (truncates the returned array) and cursor (pages from the given snapshot id); the response carries the total count.

Case	Input params	Verdict	Returned payload (overview, redacted)
all	{applicationId}	PASS	{count:70, snapshots:[{id:SNAPSHOT_ID, name, project:{name}}, ...]}
limit	{applicationId, limit:3}	PASS	returns exactly 3 snapshots; count stays 70 (total)
cursor	{applicationId, limit:3, cursor:SNAPSHOT_ID}	PASS	returns the 3 snapshots that follow the given id (paging works from a supplied cursor)
bogus applicationId	{applicationId:"zzzzzzzzzz"}	PASS	{content:{code:not_found}, code:404, isError:true}

Note: the underlying route returns count + snapshots only; it does not emit a meta.next_cursor, so a caller pages by passing the last returned snapshot's id as the next cursor. Not changed by this PR.

platform_list_team_instance_statuses

Lists each application in a team with the live status of its hosted and remote instances. associationsLimit caps how many instances/devices are returned per application.

Case	Input params	Verdict	Returned payload (overview, redacted)
valid	{teamId}	PASS	{count:1, applications:[{id:APP_ID, instances:[{id:INSTANCE_ID, meta:{state:"running", lastStartTime, versions, isDeploying:false}}, ... x11], devices:[]}]}
associationsLimit	{teamId, associationsLimit:1}	PASS	same application, instances array capped to 1
bogus teamId	{teamId:"zzzzzzzzzz"}	PASS	{content:{code:not_found}, code:404, isError:true}

platform_get_application_audit_log (extended)

Reads the application audit log (newest first). The extension adds includeChildren, which combines with scope to pull in descendant entries. Also exercised: cursor/limit, free-text query, and event (single or array) filters.

Case	Input params	Verdict	Returned payload (overview, redacted)
default	{applicationId, limit:2}	PASS	{count:1, log:[{event:"application.created"}]} (application scope)
scope=project + includeChildren	{applicationId, limit:2, scope:"project", includeChildren:true}	PASS	{count:2804, all entries scope.type=project} - descendant entries pulled in
event filter	{applicationId, limit:5, event:"application.device.unassigned"}	PASS	{count:0, log:[]} (no such events on this app)

Conclusion

The 3 new/edited tools in applications.js are verified against their descriptions: snapshot listing with working limit/cursor paging (project:snapshot:list), per-application live instance status with associationsLimit (team:projects:list), and the audit-log read with the new includeChildren plus scope/query/event filters (application:audit-log), including the not-found paths. Backing scopes were already allow-listed, so no permissions change was needed.