CW-037 · Register the employee app for push

Priority P2 · Area mobile · Estimate M · Phase 4

The backend sends push through FCM and POST /notifications/devices has always existed, but the Flutter app never calls it. So push delivery works and has nowhere to go: no device has a token registered, and every send finds an empty list.

Scope

• firebase_core and firebase_messaging, with the Android and iOS project configuration each needs.
• Ask for permission at a moment that makes sense — after the first approval the person submits, not on the splash screen.
• Register the token after sign-in and refresh it when FCM rotates it; unregister on sign-out, or the next person to use the phone gets somebody else's leave approvals.
• Open the screen the notification points at when it is tapped: the payload already carries type and notificationId.

Acceptance

• A leave approval arrives on a real device within a minute of the decision.
• Signing out stops the notifications for that account on that device.
• A revoked or expired token is removed rather than retried — the backend already deletes what FCM reports as UNREGISTERED, so this is about not re-registering a stale one.

Files mobile/lib/core/, mobile/lib/features/auth/, mobile/android/, mobile/ios/

Phase 4 rather than sooner: the pilot is five to twenty people on leave and attendance, its notification need is met by email alone, and standing up a Firebase project is real operational overhead to carry for that.

Written by the session doing the implementation work, and mirrored here from docs/backlog.md.

Start in mobile/lib/core/ and mobile/lib/features/auth/, then review mobile/android/ and mobile/ios/ for Firebase configuration and the existing POST /notifications/devices flow. Trace sign-in, sign-out, and the first leave-approval submission to choose the permission point and notification navigation using type and notificationId. Done means real-device delivery, token refresh and cleanup, sign-out isolation, and correct tap routing.