capsite/webapp: rotate the cookie in place

The cookie moves out of the immutable init into a MapStore (key shape
"cookie", value M.string()) in the instance's DO storage. Handles get
its read-only view via the new WebApp.withHeaderMap, which reads at
every send, so a rotation reaches handles already out and the webapp
id, and with it the cache's wiring, stays put (checklist goal 6).

Whoever holds the id can rotate, by RPC (WebAppFactory.cookies(id)) or
POST /at/<id>/cookie; the diigo account owner revokes by logging out.

Durable state: instances minted earlier keep the cookie in
init.headers. The first handle() moves it to the store and rewrites
init without it, in one transaction. Code from before this commit
would then see no cookie, so rolling back past it needs the reverse
move.

webapp gains a package.json and a vitest workerd pool for the tests.

Generated-by: Claude Opus 5.5

capsite-checklist.md

@@ -109,10 +109,10 @@ narrative.
               weekly page renders against prod.
   - [ ] **6. Cookie expiry**: when diigo's session ends, head refreshes
         fail; the public page keeps serving what's stored (say so on the
-        page, don't fail silently). Rotation is manual: re-mint via
-        `/_connect`. Open question: can an existing cache be re-wired to
-        a new webapp id (keeping its cache id and public username), or
-        does re-mint mean a new cache? Prefer re-wire — durable ids.
+        page, don't fail silently). Rotation is in place, keeping the
+        webapp id (so the cache's wiring and ids hold): `POST
+        /at/<id>/cookie` with the new cookie (webapp README, "The cookie
+        store"). Still open: a rotate form in diigo-cache's UI.
   - [ ] **7. bib sync #195**: repeat the pattern for the next
         read-access need (webapp mints for any origin; the cache's
         item shape is diigo-specific): [the zotero goal tree](zotero-checklist.md).