REST + CLI mirror for contributor notifications (list + mark-read)

[JSONbored]

Context

The MCP tools loopover_list_notifications (src/mcp/server.ts:2177) and loopover_mark_notifications_read (src/mcp/server.ts:2188), both self-scoped via requireContributorAccess, have no REST equivalent. Grepping src/api/routes.ts for "notification"/"subscription" finds no contributor-facing notification-feed route — only /v1/app/notification-model (a static describe-the-model endpoint) and /v1/app/digest/subscriptions (unrelated email-digest signup). The route file's own comment at src/api/routes.ts:5875-5879 explicitly frames notifications as an MCP-parity concern the REST leg was never built for.

Requirements

• Add GET /v1/contributors/:login/notifications and POST /v1/contributors/:login/notifications/read in src/api/routes.ts, reusing requireContributorAccess exactly as /v1/contributors/:login/profile and /decision-pack already do.
• Add corresponding CLI stdio tools/subcommands for both.

Deliverables

• GET /v1/contributors/:login/notifications route
• POST /v1/contributors/:login/notifications/read route
• CLI stdio tools for both
• Unit tests

Test Coverage Requirements

99%+ Codecov patch coverage on every changed line and branch in the new route/tool/CLI code, plus a test asserting output parity between the mirrored surfaces for identical input.

Expected Outcome

A contributor's notification feed is readable and markable-read over REST/CLI, not just MCP.

Links & Resources

Precedent: app.get("/v1/contributors/:login/profile", ...) (src/api/routes.ts:3093) and app.get("/v1/contributors/:login/decision-pack", ...) (src/api/routes.ts:3108) — same auth helper, same route family.

[linear-code]

JSO-4559

[RealDiligent]

Working on this — REST + CLI mirrors for loopover_list_notifications / loopover_mark_notifications_read.