fix(ui): handle notification_status from the shell and offer a manual retry

[sanity]

Problem

River's shell-bridge listener (ui/src/components/app/notifications.rs) dropped
every message whose type was not notification_click:

if kind != "notification_click" {
    return;
}

The gateway shell reports the outcome of its permission offer as
notification_status (notifyStatusToIframe in freenet-core's
shell_bridge.js), with granted / denied / dismissed / undeliverable /
unsupported / default. All six were discarded identically, and
notification_status appeared nowhere in ui/src. River could not tell a
granted permission from a blocked one and surfaced nothing to the user.

Worse, request_enable_via_shell was latched by a ENABLE_PROMPT_SENT
AtomicBool with no reset, and the bell modal only chose All / Mentions /
Muted — so a prompt that was blocked, snoozed, or mis-clicked could not be
re-requested for the rest of the session. Net effect: notifications silently
never worked, with no explanation and no path to fix it.

This is River's half only. The shell-side defect is freenet/freenet-core#4966;
nothing here depends on it — the shell already sends notification_status on
main.

Approach

Consume the status. A new notification_status arm parses the shell's
status string into a NotificationStatus enum and records it in a
NOTIFICATION_STATUS global. An unrecognised string is ignored rather than
guessed at, so a newer shell adding a status can never overwrite a known one
with a wrong reading. The signal write goes through crate::util::defer, as
required for a write originating in a JS MessageEvent callback
(.claude/rules/dioxus-signal-safety.md), and record_notification_status is
the only writer so no path can bypass the re-arm below.

Re-arm the ask, bounded. A status of default (the prompt closed with no
answer) clears ENABLE_PROMPT_SENT so a later gesture can offer again. The
re-arm is capped at one, because the shell re-shows its affordance every time
River asks: uncapped, a user who keeps closing the browser dialog would get the
bar back on every message they send. dismissed deliberately does NOT re-arm —
the shell also snoozes it for 24h, so River re-asking would just bounce off that
snooze.

Surface it, and offer a retry. The bell modal grows a "Browser permission"
section with a short explanation and an "Enable notifications" button. The
button is offered exactly where asking again can change the answer (dismissed,
default, or nothing known yet) — offering it against a browser-level block or
an already-granted permission would just move the silent dead end. Its click
calls request_enable_now() directly, not through crate::util::defer,
because the browser only honours a permission request made inside the click's
transient user activation and defer is a setTimeout(0).

The manual path is deliberately not latched: the once-per-session latch exists
so sending messages doesn't nag, and an explicit click is exactly the retry it
must not swallow.

Served top-level (dev / no-sync) River has a real origin, so the same button
calls the Notifications API directly. Notification::request_permission() is
invoked synchronously inside the click for the activation reason above; only the
awaiting of the already-created promise is deferred. This incidentally avoids
the lost-activation problem the issue notes for the existing auto path, which is
otherwise unchanged.

One bug found while writing this: current_notification_status reads
Notification.permission on every modal render, and web_sys's binding for it
is not Result-returning — reading .permission off an undefined Notification
raises a JS ReferenceError that aborts the WASM module. Guarded by
notification_api_available(). Playwright's mobile-safari project has no
Notifications API at all, so this was reachable.

Testing

cargo test -p river-ui --bins: 785 pass (10 new). New coverage:

• The six shell status strings parse to distinct variants (a cross-repo wire
  contract — a rename on either side reverts the fix exactly), and unrecognised
  strings are ignored.
• Only an unanswered prompt re-arms the automatic ask, and the re-arm is bounded.
• The Enable button is offered exactly where asking again can help, and every
  state has its own non-empty explanation.
• Source pins for the parts no native test can reach (a JS closure and rsx): the
  listener consumes notification_status; the status write stays inside
  defer and has exactly one writer; request_permission() is called before the
  spawn; the Enable click is not deferred.

Every new test was mutation-tested — the fix reverted or subtly broken in eight
ways, each caught by a named test. One of the eight (raising the re-arm cap to
usize::MAX) initially passed, because the bound assertion was phrased against
the constant it was testing and so held for any cap at all; that vacuous test is
fixed in its own commit.

Playwright notification-bell.spec.ts: 30 pass across chromium, firefox, webkit,
mobile-chrome and mobile-safari. The new spec asserts the explanation always
renders and that the button appears iff the browser state is one where asking
again helps. The five projects cover all three branches — Chromium reports
denied, Firefox and desktop WebKit default, mobile Safari has no API. Both
new data-testids are absent on main, so the spec fails there.

Manually verified in Firefox that clicking the button leaves the app alive and
the modal rendered, with no new console error.

Closes #510

[AI-assisted - Claude]

[sanity]

Review

Two independent adversarial lenses, run serially against the checked-out code (no subagents available in this session). Per ~/.claude/rules/multi-model-review.md as amended 2026-07-26, external non-Claude models are opt-in and were not invoked.

Lens 1 — code-first (read the code before the description; intent vs implementation)

Two findings, both fixed in c8e0126:

1. Stale permission on the top-level path (medium). current_notification_status preferred the value River remembered from its own last request over the browser's own answer. A user who denied once and then allowed notifications in site settings would be told "your browser is blocking notifications" for the rest of the session, with the Enable button withheld — a stale silent failure of exactly the shape this PR removes. The browser is authoritative when River is served top-level and stays authoritative, so the remembered value is now ignored there. It is still read, because the read is what subscribes the render to the signal; dropping the read would stop the modal updating when a request completes. The precedence is now a pure resolve_status(framed, stored, live) with tests.

2. dismissed copy promised a retry that doesn't work yet (low). That status also covers "inside the gateway's snooze window from an earlier decline", during which asking again provably shows nothing for up to a day. The old wording ("You can ask for it again") would have put the user back in front of a control that silently does nothing. Reworded to say the prompt may not reappear straight away.

Checked and found correct: all six notifyStatusToIframe strings are covered; the source/__freenet_shell__ checks still gate the new arm; record_notification_status is the only writer, so no path can skip the re-arm; read_browser_permission is invoked lazily via bool::then, so the framed path never reads a meaningless opaque-origin permission.

Lens 2 — skeptical + testing (assume bugs exist; does the status actually reach the UI?)

No new defects.

Does it silently no-op when the shell sends nothing? No. Framed with no status ever reported, resolve_status returns None, which is its own state: the user sees "Desktop notifications are not set up yet for this browser." plus a working Enable button. Both orderings work — a status arriving before the modal opens is read from the signal on open; one arriving while it is open re-renders it through the try_read subscription. defer is safe here because capture_runtime() runs earlier in App() than install_shell_notification_listener().

Against an older gateway shell that predates notifyStatusToIframe, no status is ever sent, so the modal shows the "not set up yet" state and the Enable button posts notification_enable_prompt — a message old shells already handle. Degrades to today's behaviour plus a manual trigger, never to a crash.

Would the tests fail if the fix were reverted? Verified by mutation, not by inspection. Nine mutations, each caught by a named test:

Mutation	Caught by
Delete the notification_status arm	the_shell_listener_consumes_notification_status
Move request_permission() inside the spawn	the_direct_permission_request_stays_inside_the_click_gesture
Drop the defer around the signal write	the_status_write_is_deferred_and_has_one_writer
Wrap the Enable click in defer	the_enable_click_is_not_deferred
Let dismissed re-arm the auto ask	only_an_unanswered_prompt_rearms_the_automatic_ask
Offer Enable on denied	enable_is_offered_exactly_where_asking_again_can_help
Rename the "default" token	every_shell_status_string_parses
Change the re-arm cap constant	the_automatic_rearm_is_bounded
Break the re-arm counter	covered NOT COVERED — see correction below
Prefer the remembered status over the live one	the_browser_answer_wins_over_a_remembered_one_when_unframed

The re-arm-cap mutation initially passed: the assertion was phrased against MAX_ENABLE_PROMPT_REARMS itself, so it held for any cap including none. Fixed in 423ce60 to assert concrete numbers.

Known gaps, accepted

• No native test drives the real atomics. Only the pure status_rearms_auto_prompt predicate is tested. The statics are process-global and native tests run in parallel threads, so a test mutating them would be flaky and could corrupt a sibling. The predicate plus the one-writer pin is the trade.
• No browser test of the framed branch. Simulating the shell would mean standing up a fake shell page posting notification_status. The decision is covered by resolve_status's unit tests and the wire contract by the status-string test.
• The latent activation problem on the automatic path is not fixed here, deliberately. As the issue notes, request_permission_on_first_message is reached several awaits deep in the send pipeline, so activation is already gone before safe_spawn_local is involved — removing the spawn would not fix it. A real fix means moving the trigger to the send button's click handler, which changes when River prompts. The new manual button gives affected users a working path in the meantime.

[AI-assisted - Claude]

---

Correction (2026-07-29)

The mutation table above overstated one row, and I am correcting it in place rather than leaving the wrong claim standing.

I originally listed "Remove the re-arm cap" as covered by the_automatic_rearm_is_bounded. That is true only for changing the constant. It is false for breaking the counter: that test asserts MAX_ENABLE_PROMPT_REARMS <= 2 and calls the predicate with a caller-supplied rearms_used, so it passes with ENABLE_PROMPT_REARMS.fetch_add(1, ...) deleted.

Independent review confirmed by execution that both statements of the re-arm could be deleted with the whole suite green:

baseline                                        787 passed
delete ENABLE_PROMPT_REARMS.fetch_add(1, ...)   787 passed   <-- survived
delete ENABLE_PROMPT_SENT.store(false, ...)     787 passed   <-- survived

So the "reset the flag" half of #510 shipped here with no coverage at all. Dropping the SENT reset means an unanswered prompt never re-arms; dropping the REARMS increment leaves the counter at 0, making the re-arm unbounded so the shell's affordance bar returns on every message sent.

My "known gaps, accepted" note above correctly ruled out a behavioural test (process-global statics vs parallel test threads) but stopped there, missing that a source pin has no parallelism problem — an idiom this same file already uses four times.

Fixed forward in #550, along with a vacuous browser assertion, a debug! that is compiled out in release, and the bell-level visibility gap. That PR's pin is verified by watching it fail with each line deleted.

[AI-assisted - Claude]

[sanity]

Review follow-up: the framed-branch gap is now closed

The review above listed "no browser test of the framed branch" as an accepted gap. It turned out to be cheap to close: invitation-sandbox.spec.ts already establishes a fake-gateway-shell fixture, and notification-shell-status.spec.ts (2501da3) reuses that shape. A minimal shell parent page posts notification_status down to a River iframe and counts the notification_enable_prompt messages River posts up.

That covers, in a real browser and a real cross-frame postMessage, the whole path no native test in a WASM crate can reach: framing detection, the listener arm, the deferred signal write, the framed branch of resolve_status, the notice mapping, and — the half of #510 the one-way latch made impossible — that the manual retry actually reaches the shell, twice in a row.

Mutation-verified rather than assumed. I deleted the notification_status arm, rebuilt the UI, and re-ran the spec: both tests fail, on toContainText — the modal renders but the status never changes what it says, which is #510 exactly. Restoring the arm and rebuilding returns all 10 (2 tests x 5 browser projects) to green.

Local runs on the final code: cargo test -p river-ui --bins 787 pass; Playwright notification-bell + notification-shell-status 40 pass across chromium, firefox, webkit, mobile-chrome and mobile-safari.

Two gaps remain accepted, unchanged: no native test drives the real atomics (process-global statics vs parallel test threads), and the latent activation problem on the automatic prompt path is deliberately out of scope, since the activation is already lost before safe_spawn_local is reached and a real fix would change when River prompts.

[AI-assisted - Claude]