clients: S-D29 client half — native alert delivery, notification.* keys, permission at first use

[justin13888]

The core half of S-D29 landed in #411: capsule-core::notify is the shared decision function
(evaluate(&NotifyInput, now) for the classes true at an instant, next_deadline(&NotifyInput, now)
for the one instant to arm), and capsule-sdk::ffi exports both as free functions with RFC 3339
timestamps. S-D29 stays ready because nothing on a device evaluates it yet: every predicate
input is caller-supplied, since the core holds none of the trigger state.

This is the remainder — the delivery half, which is the larger one.

Owed:

• Native scheduling and presentation. iOS UNUserNotificationCenter with
  UNCalendarNotificationTrigger / UNTimeIntervalNotificationTrigger; Android
  NotificationManagerCompat scheduled via AlarmManager.setExactAndAllowWhileIdle (or
  WorkManager where inexact timing is acceptable). No abstraction layer — the design says
  native APIs directly.
• The arm / re-arm / cancel loop, per client. Call next_alert_deadline after any state
  change and cancel-then-arm if the value moved. next_alert_deadline withholds a deadline
  whenever the alert would not certainly be true on arrival, so an armed notification never
  needs re-checking at fire time — which is the whole point, since it fires with the app not
  running.
• The three server-state classes surface at next app launch. quota_soft,
  quota_grace_expiring, quarantine_pending and drop_pending are not pre-armable, by
  design. Closing that gap is the post-v1 wake tier, not this issue.
• The client's own state, wired into FfiNotifyInput. Nothing persists the fields today:
  the last completed sync instant and the un-synced count, the last GET /v1/quota state, the
  quarantine-surface count, and the pending-drop count. RecoveryCadence::notify_facts already
  covers the recovery half.
• Snooze and disable, per class. They ride FfiNotifyInput.suppressed_until (class wire
  name to an instant, exclusive), so the client owns the bounded-snooze-then-badge state and
  the core does not get a second copy of a mechanic the recovery cadence already implements.
  Disabling suppresses the warning and never the behavior.
• The notification.* catalog keys in locales/, one per class, with the parameters the
  predicate emits (count, days_behind, grace, snooze_budget). Blocked until now by the
  i18n guard, which requires a live consumer — that consumer is this issue.
• Permission at first use. Android POST_NOTIFICATIONS from API 33 and the iOS
  authorization prompt, requested the first time a class has something to say rather than at
  launch, so the prompt carries context. A denial degrades every class to its in-app badge:
  no error, no retry, no failed flow.
• Validation. The pre-arm lifecycle under a mocked clock (arm on deadline-known, re-arm on
  the change that moves it, cancel when it clears, never two live timers per class); the snooze
  bound degrading to a badge; a refused authorization degrading to a badge without error; and
  the per-platform smoke that fires a pre-armed alert with the app terminated — the one gate
  the core half could not run.

Contract: capsule-docs/src/content/docs/design/notifications.md (Delivery, Shared Alert
Mechanics, Validation). Ledger: the S-D29 row and detail block in SLICES.md.

Refs #411

[justin13888]

Correction to the owed work above, after review round 1 on #433.

Two items in the list above are now wrong. The core half changed while it was in review; this comment supersedes them. Nothing else in the issue changes.

1. The arm/re-arm/cancel loop is per class, not one global timer.

The bullet above says to "call next_alert_deadline after any state change and cancel-then-arm if the value moved." Do not build the client that way. next_alert_deadline returns the earliest deadline across the pre-armable classes, so a client that arms only it loses the later class's alarm entirely — with a staleness deadline two weeks out and a recovery check ninety days out, arming the minimum means the recovery alert never fires on a device the app is not opened on again. That is the exact case pre-arming exists for.

The contract is instead:

Call pre_arm_deadlines(input, now), which returns one entry per class (FfiClassDeadline { class, deadline }). Reconcile your timers against it: a class present holds exactly one alarm at that instant; a class absent holds none — cancel whatever it has. Recompute after any state change. The class in each entry is also what selects the notification.* catalog key for the alarm being armed.

next_alert_deadline remains exported, but only as a convenience for a host that can physically hold one timer (a desktop scheduler, a CLI). It is lossy by construction and is not what a mobile client should use.

An alarm fires with the app not running and so cannot be re-checked on arrival; pre_arm_deadlines therefore returns an instant only when the alert is certain to be true when it gets there. It withholds one for a class that is not pre-armable, for an instant already past, for a disabled class, for sync_stale with nothing un-synced, and for recovery_check_due with its snooze budget spent (that class has degraded to a persistent badge, which is in-app — evaluate_alerts still reports it, carrying snooze_budget = spent, so there is something to render the badge from).

Snooze and disable are separate inputs: FfiNotifyInput.suppressed_until (a snooze, which defers the alarm to the snooze end rather than cancelling it) and FfiNotifyInput.disabled (which cancels). Recovery snoozing belongs in recovery_snoozed_until, not the generic map.

2. The notification.* catalog keys take five parameters, not four.

The parameters list above omits recovery. The full set the predicate emits, now also recorded in design/notifications.md's alert-class table and design/backup-recovery.md:

Class	Parameters
sync_stale	count, days_behind
recovery_check_due	snooze_budget (available / spent), recovery (check / rewrap)
quota_grace_expiring	grace (counting / expired)
quarantine_pending	count
drop_pending	count
quota_soft	(none)

recovery is the one that changes behaviour rather than only copy: on rewrap the user has had repeated verification failures or has explicitly declared the secret lost, and the client must route into the guided re-wrap flow instead of rendering a routine verification prompt. The alert class set is closed, so this parameter is the only way those two are distinguishable.