feat(mcp): notification and self-service read tools

[andypalmi]

Summary

Adds Phase 1 read-only MCP tools for user self-service #7702 .

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

Tools added:

• platform_get_current_user - GET /api/v1/user
• platform_list_notifications - GET /api/v1/user/notifications (paginated)
• platform_list_own_invitations - GET /api/v1/user/invitations

All three are tagged 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.

Write, delete, and admin-only endpoints from the parent issue #7703 #7704 are out of scope for this PR, as are the excluded sensitive self-service routes (change_password, account deletion, MFA, tokens).

Closes #7702

Test plan

• eslint clean on changed files
• CI

[codecov]

Codecov Report

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

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #7718      +/-   ##
==========================================
+ Coverage   75.94%   75.96%   +0.01%     
==========================================
  Files         445      446       +1     
  Lines       23990    24002      +12     
  Branches     6404     6404              
==========================================
+ Hits        18220    18232      +12     
  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.

[cstns]

this endpoint does not support pagination

[andypalmi]

GET /api/v1/user/notifications does paginate. It runs through getNotifications in forge/services/notifications.js, which calls app.getPaginationOptions(request) and passes it to Notification.forUser, and the response carries meta and count. Confirmed against a running instance: platform_list_notifications { limit: 1 } returned 1 of 4 notifications with meta.next_cursor set, and passing that cursor back returned the next entry. So cursor and limit are correct on this tool.

[cstns]

this one is paginated

[andypalmi]

GET /api/v1/user/invitations does not paginate. It calls Invitation.forUser(request.session.User) with no pagination options and always returns meta: {} (that line carries a // For future pagination note in forge/routes/api/userInvitations.js), returning every invitation. Confirmed against a running instance: with two pending invitations, platform_list_own_invitations { limit: 1 } still returned both, and { limit: 1, cursor: "bogus" } returned the same two with no error. So the params have no effect, which is why this tool has no pagination params; we can add them if the endpoint gains real pagination later.

[andypalmi]

Verified the pagination behavior by invoking the tools against a local instance.

platform_list_notifications (account had 4 notifications):

• {} -> count 4, meta: {}, 4 items
• { limit: 1 } -> count 4, meta: { next_cursor: <id> }, 1 item
• { limit: 1, cursor: <that id> } -> next item, meta: { next_cursor: <next id> }
• { limit: 50 } -> count 4, meta: {}, 4 items

platform_list_own_invitations (account had 2 pending invitations):

• {} -> count 2, meta: {}, 2 items
• { limit: 1 } -> count 2, meta: {}, 2 items (limit ignored)
• { limit: 1, cursor: "bogus" } -> identical, no error

Conclusion: notifications supports cursor/limit; invitations does not, matching the current tool schemas.