Be somewhere a phone can share to

ihasmail could hand a file to the share sheet as of #306, and was still
not in it. Share a photo from the gallery, a link from the browser or a
document from a file manager and ihasmail was not among the places it
could go, which is the one piece of operating-system integration a mail
app is expected to have.

A share is a POST that navigates, and there is nothing on this side that
can answer one: the app is a client-side router with no endpoint at that
address, and the server behind it would need a route that understood the
composer. So the service worker intercepts it, takes the form body, puts
the files and text in its cache, and redirects to the app -- which finds
them on start and opens a draft holding them. The subject is the shared
title, the text and the link become the body, and files are attached and
begin uploading. Nothing is addressed: a share says what to send, never
who to.

The body is pushed in above the signature rather than passed to open(),
because open() only fits a signature when it is given no body at all --
the obvious version drops the signature from every message that started
as a share, and nothing about the draft looks wrong afterwards.

Collected on every start rather than when the launch URL says so. A share
to a signed-out ihasmail lands on the sign-in page, and there is no
account to attach to until it is done, so the payload has to outlive a
redirect and a login -- which the query string does not. What that costs
is a stash nobody came back for, so it carries a timestamp and expires
after ten minutes.

`accept` names wildcard families and explicit types and extensions both.
A mail client attaches anything, but wildcards are not in the
specification and operating systems differ over which form they match on,
so the explicit list is what holds if the families are ignored.

The cache name the worker and the app have to agree on now has one home
on the app side. It was written out twice, and a drift would not fail --
a push verification would simply never complete and a share would arrive
at an empty composer.

One case is deliberately left to fail loudly: an app still installed
whose worker has been cleared away POSTs to the server, which answers
405. A server route would trade a plain error for a silent nothing, and
the payload is gone in both -- it only ever existed in that request body.

Verified by test, not on a device: Android is the only place this exists
at all, and the extension driving Chrome is not connected here. The
handoff is pinned from the tab's side against a cache shaped exactly as
the worker leaves it, since the two files never see each other.

web/public/sw.js

@@ -30,8 +30,74 @@ self.addEventListener("activate", (event) => {
   );
 });
 
+/*
+ * Where a share from the operating system is left for a tab to collect.
+ *
+ * Absolute and anchored to the mount, for the same reason the verification key
+ * below is: a relative key is resolved against the URL of whoever asks, and the
+ * worker and a tab deep in `/mail/inbox/…` are not at the same place.
+ *
+ * The files go in one entry each and the rest in a JSON index beside them,
+ * because the Cache API stores Responses and a File is already one body.
+ */
+const SHARE_KEY = `${BASE}/ihasmail-share`;
+const SHARE_MAX_FILES = 20;
+
+/*
+ * Take delivery of a share.
+ *
+ * This is a POST that navigates: the operating system submits a form at the
+ * app and expects a page back. Nothing in ihasmail can answer it directly --
+ * the app is a client-side router with no endpoint at that address, and the
+ * server behind it would have to grow one that understood the composer. So the
+ * worker takes the body, puts it where a tab can find it, and redirects to the
+ * app, which then opens a draft holding it.
+ *
+ * The redirect happens whatever went wrong. A share that fails to stash costs
+ * whatever was being shared, which is bad; a share that fails to *respond*
+ * costs that and leaves the reader looking at a browser error page where they
+ * expected their mail, which is worse.
+ *
+ * There is one case this cannot cover, and the server is deliberately not
+ * taught to: an app still installed whose worker has been cleared away. The
+ * POST then reaches the server, which answers 405, and the share is lost
+ * either way -- the payload only ever existed in that request body. A server
+ * route would trade a plain error for a silent nothing, and a share that
+ * vanishes without saying so is the harder of the two to notice.
+ */
+async function stashShare(request) {
+  try {
+    const form = await request.formData();
+    const cache = await caches.open(VERSION);
+    const meta = {
+      at: Date.now(),
+      title: String(form.get("title") ?? ""),
+      text: String(form.get("text") ?? ""),
+      url: String(form.get("url") ?? ""),
+      files: [],
+    };
+    const files = form.getAll("files").filter((f) => f && typeof f === "object" && "name" in f && f.size > 0);
+    for (const [i, f] of files.slice(0, SHARE_MAX_FILES).entries()) {
+      const key = `${SHARE_KEY}/${i}`;
+      await cache.put(key, new Response(f, { headers: { "content-type": f.type || "application/octet-stream" } }));
+      meta.files.push({ key, name: f.name || `file-${i + 1}`, type: f.type || "application/octet-stream" });
+    }
+    await cache.put(SHARE_KEY, new Response(JSON.stringify(meta), { headers: { "content-type": "application/json" } }));
+  } catch {
+    /* nothing to hand on: the app opens on an empty inbox rather than an error */
+  }
+  // Absolute, because `Response.redirect` rejects a bare path outright rather
+  // than resolving it -- so `${BASE}/mail` would throw here and the share
+  // would end at a browser error page instead of the inbox.
+  return Response.redirect(new URL(`${BASE}/mail?share=1`, self.location.origin).href, 303);
+}
+
 self.addEventListener("fetch", (event) => {
   const req = event.request;
+  if (req.method === "POST" && new URL(req.url).pathname === `${BASE}/share`) {
+    event.respondWith(stashShare(req));
+    return;
+  }
   if (req.method !== "GET") return;
   const url = new URL(req.url);
   if (url.origin !== self.location.origin) return;