Prove cookie injection lands, rather than assuming it

setCookie is fire-and-forget, so the import's count was what WebKit was
handed, not what it kept. A probe from inside the page reads back the
other end: pairing against Arc gave `names=tz,cids,frontend_lang` for
aputure.odoo.com, and `tz` exists only in Arc's store — so the import
demonstrably landed.

The sites still ask for sign-in. That is the far end refusing the
session, not a broken import, and the two are now distinguishable
instead of being guessed at.

docs/superpowers/specs/2026-09-01-work-app-design.md

@@ -149,6 +149,17 @@ Settings lists the browsers actually installed. Pairing with a Chromium browser:
    list. Nothing else is read out of the browser.
 4. Inject them into `WKHTTPCookieStore`.
 
+**Verified on the machine.** Pairing against Arc imported 43 cookies across 9 domains,
+and a probe from inside the page then read back `host=example.odoo.com
+names=tz,cids,frontend_lang visible=3` — `tz` existing only in Arc's store, which is what
+proves the import landed rather than merely being handed over. `setCookie` is
+fire-and-forget, so the import's own count could never have shown this.
+
+The sites still presented sign-in pages. That is the documented limitation, not a broken
+import: the cookies are in the store and visible to the page, and the session is being
+refused at the far end. Settings keeps the probe as **Check cookies**, so the same
+question can be answered again without guessing.
+
 Pairing is a button, not a background job. Cookies rotate; a silent task that periodically
 reaches into the Keychain is worse than one the user presses when something logs them out.