feat(notification): add unread count and per-notification read

[aquie00t]

Closes findings 6-7 of the notification audit, following #221.

What was missing

6. No unread-count endpoint. getUnreadCount() was implemented on the repository and declared on the port, but nothing called it — dead code. The badge could only be built by paging through the whole list and counting client-side.

7. Read state was all-or-nothing. PATCH /notifications/read-all was the only way to mark anything read, so tapping a single notification had to clear every one of them.

New endpoints

GET /notifications/unread-count	{ data: { count }, meta: { timestamp } }, STANDARD rate limit
PATCH /notifications/:id/read	204, or 404 when the notification is not the caller's

The single update goes through updateMany with where: { id, recipientId } rather than update by id. That puts the recipient in the filter, so another user's notification simply matches nothing — it answers 404 exactly like an id that does not exist, instead of leaking that the id is real.

Three defects fixed on the way

PATCH /notifications/read-all marked every user's notifications as read. The controller called execute(userId) with a bare string while the use case takes { userId }. It destructured to undefined, and Prisma drops an undefined filter, so updateMany ran with no recipientId condition at all — across the whole table. The new e2e case asserts a second user's unread count survives someone else's read-all.

request.user was any project-wide. src/http/types/fastify-jwt.d.ts imported UserPayload from @core/interfaces/user-payload.interface, a path that stopped existing when the type moved to the token port in d4a508c. skipLibCheck: true means declaration files are not checked, so the dangling import never surfaced and FastifyJWT["user"] silently degraded to any — which is why the bug above type-checked for as long as it did. Repointing the import makes tsc catch it. payload is now UserPayload | RecoveryPayload, since the account-recovery token is signed with the same instance.

notificationController was any in the Cradle. src/http/types/fastify-awilix.d.ts imported it from @services/notification.controller, an alias that is not in tsconfig.json. Fixed for this controller; six others (auth, oauth, user, profile, follow-user, post) still use the same dead alias and are left for a follow-up, since fixing them all is a separate diff.

Verification

• pnpm test:unit — 792 passed (7 new)
• pnpm test:integration — 107 passed (3 new: single read, cross-user refusal, unknown id)
• pnpm test:e2e — 325 passed (new tests/e2e/notification/read-state.test.ts: counts scoped per user, 204 + count drop, idempotent repeat, 404 for someone else's, 404 for unknown, 401s, and the read-all scoping regression)
• tsc -p tsconfig.build.json --noEmit, pnpm lint, prettier — clean

Integration and e2e ran before the rebase onto the merged #221; unit tests and the typecheck were re-run after it.

Still open from the audit

8 (no notification cleanup on unlike/unfollow, duplicate notifications), 9 (realtime emit inside the transaction), 10 (realtime payload shape differs from REST), 11 (WebSocketManager keeps one socket per user, so a second tab silently steals delivery), 12 (default-avatar.png fallback points at a key that does not exist), 13-14 (dead NEW_POST type, unused getDescription()).

🤖 Generated with Claude Code

https://claude.ai/code/session_01PwzkQ5YGFXSB9jWCZKzX4H

[github-actions]

🎉 This PR is included in version 1.9.0 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀