Support "Add to Home Screen" + push notifications for iOS

[JanWelker]

Add PWA support so the app can be used like a native app on iOS, including system-level push notifications.

Requirements:

• Add a manifest.json (name, icons, display: "standalone")
• Serve over HTTPS (required for both PWA install and push)
• Implement Web Push API (Notification, PushManager, service worker) for push notifications
• Notification permission request triggered by explicit user gesture, not on page load
• Small backend/serverless piece to store push subscriptions and send payloads via the push service

Constraints (iOS 16.4+):

• Push only works once the app is added to the Home Screen — Safari tabs cannot request push permission
• Removing the Home Screen icon kills the subscription; user must re-add and re-subscribe
• No silent/background push triggering app logic — visible notifications only
• Badge counts supported via navigator.setAppBadge()

Acceptance criteria:

• Manifest + icons added, app installable from Safari share sheet
• Service worker registered, push subscription flow implemented
• User can opt in to notifications via in-app button
• Notifications received on iOS 16.4+ after Home Screen install

[JanWelker]

Shipped in #307 (v7.1.0) — the installable half. Closing this one, because the notification half is not a piece of work still to be scheduled here: it cannot be built the way this issue frames it, and the alternative that can work now has its own issue.

Acceptance criteria

• Manifest + icons added, app installable from Safari share sheet — static/manifest.webmanifest, display: standalone, icons at 192/512, a maskable cut for Android's launcher crop, and apple-touch-icon (iOS takes the Home Screen icon from that link, not from the manifest). Every URL in the manifest is relative so BASE_PATH never has to be interpolated into a file static/ copies verbatim — an absolute / would point every PR preview's installed app at the production root.
• Service worker registered — src/service-worker.ts, registered by SvelteKit itself. It precaches the whole app, which is cheap here for the same reason the one-origin contract exists: the app fetches nothing from anywhere, so "the whole app" is a finite list known at build time. The plan and the print sheet now open with no signal at all.
• Serve over HTTPS — already the case.
• Push subscription flow / in-app opt-in button / notifications received on iOS 16.4+ — see below.

Why the notification half was not built

Not a scoping decision. It is not reachable from a client-side app at all:

• iOS suspends a backgrounded web app's JavaScript, so a setTimeout for a step eight hours out never runs.
• It wakes a service worker for exactly one thing — an incoming push message, which requires a server to send.
• Notification Triggers (TimestampTrigger / showTrigger), the one API that would let a page hand the OS a "fire this at 06:40" instruction, was removed from Chromium and never existed in Safari.

So the fifth bullet of this issue — "small backend/serverless piece to store push subscriptions and send payloads" — is not an implementation detail of the notification feature, it is the notification feature. That conflicts with the app being fully client-side, with server-side persistence being out of scope, and with the one-origin promise that e2e/self-hosted.spec.ts enforces. Push subscriptions are also personal data, which would mean a privacy-policy change for a static site that currently tells nobody anything.

The reasoning is written into src/app.html, src/service-worker.ts, CLAUDE.md and the README rather than left in this thread, so it does not get re-litigated from scratch.

What to do instead

Today: the .ics export. The user's own calendar fires the alarm, with the app closed, on any platform, with no server involved. That is the only client-side path to a step reminder that actually reaches someone at 03:00.

Possibly: #309 — ship as a native iOS app. Native UNUserNotificationCenter local notifications are scheduled against the system and fire with the app closed, killed, or the phone in a drawer — no server, no push, no network. The schedule is fully known the moment computeSchedule returns, and a biga+poolish cold plan is nine steps against iOS's 64-notification cap. A WKWebView shell keeps src/lib/dough/ as the single source of truth rather than reimplementing the fermentation model in Swift.

#309 is where the rest of this issue can actually land, and it composes with what shipped here: a shell loading a local bundle needs the app to work with no network, which is exactly what the service worker now does.