Fixed: register the device when subscribing from the notification preference modal (targets v5.3.0-ls)

[dt2patel]

Same code as #870, targeted at v5.3.0-ls for Lovers UAT retesting. The rationale is corrected relative to #870, which I have also commented on.

What is actually broken

subscribe#Topic in hotwax-moqui-firebase only subscribes registration tokens that already exist for the user:

<entity-find entity-name="co.hotwax.firebase.UserLoginFirebaseClient" list="userLoginClientTokens">
    <econdition field-name="userLoginId" from="ec.user.getUsername()"/>
    <econdition field-name="applicationId" from="applicationId"/>
</entity-find>

NotificationPreferenceModal, reached from the bell icon, subscribes topics and never registers the device at all. A user with no token who sets their preferences there creates topic subscriptions with nothing behind them. The backend then shows a healthy-looking subscription for a user who can never receive anything from that path.

initialiseFirebaseMessaging also refused to run for exactly these users, because it required getAllNotificationPrefs to be non-empty, which is only true once a subscription exists.

Change

• Register the device before subscribing, in both Settings.vue and NotificationPreferenceModal.vue.
• Add a force parameter to initialiseFirebaseMessaging. The default is unchanged so users who never asked for notifications are not prompted on login, but a caller about to subscribe overrides it. Existing no-argument callers in App.vue and store/user.ts are unaffected.
• Stop an unset or malformed VITE_FIREBASE_CONFIG throwing out of JSON.parse, which previously rejected the whole post-login flow instead of degrading to notifications being unavailable.

Correction to what I originally claimed

I first said the Settings ordering itself was the bug. It is not. store#ClientRegistrationToken back-fills, subscribing a newly created token to every topic the user already holds, so the old order worked there. The reordering in Settings.vue is neutral and kept only for consistency with the modal. The modal fix is the substantive one.

The larger defect is in the backend, not this PR

store#ClientRegistrationToken looks its row up on (userLoginId, deviceId, applicationId) and ignores registrationToken. When FCM rotates a token for a device that already has a row, the service returns early, never updates the stored token and never subscribes the new one. The database keeps a dead token, the live token belongs to no topic, and the device goes silent permanently with no error raised. That fits "worked for a few orders then stopped" far better than anything in this PR, and it cannot be fixed from the frontend.

🤖 Generated with Claude Code

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-09-16T04:07:42.309722Z	4881401	PR opened

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[dt2patel]

Superseded by the PR above. This branch was cut from a v5.3.0-ls that is now 28 commits stale, so it would have reverted unrelated work. More importantly @ymaheshwari1's #859 approach has since landed on this branch, which removes the preference gate from initialiseFirebaseMessaging more cleanly than the force parameter here, and my claim that the subscribe-then-register ordering was the root cause was wrong: store#ClientRegistrationToken back-fills. The replacement keeps only what is genuinely still missing, the preference modal never registering the device, and the unguarded config parse.