Price the Storage Access route as it really stands: not reachable today

The section sold it as a permission prompt on top of the existing flow. A
browser denies requestStorageAccess outright when the embedded origin has no
recent first-party interaction to grant against, and remark42 never gets one:
the reader interacts on the provider's origin, and the callback returns to a
document whose first statement is window.close() under ?selfClose. So the real
cost is changing the first-party experience, either by having the callback
collect a click before closing or by establishing interaction some other way,
which is a different order of cost from the other two routes.

Also states the grant correctly. It lets the frame's requests carry the cookie;
it does not make it script-readable, and the JWT cookie is HttpOnly regardless,
which is what the OAuth paragraph above already says.

docs/plans/2026-08-19-frontend-simplification.md

@@ -52,11 +52,22 @@ Two routes could bring OAuth inside the criterion, and both need costing before
 mandatory.
 
 The first is the Storage Access API, which exists for exactly this shape: an embedded frame asks
-the browser, with a user gesture, for access to its own unpartitioned first-party cookies, and
-Safari and Chrome both implement it. That would let the frame read the cookie the callback already
-set, with no backend work at all. It is not free, since it spends a permission prompt and the
-grant is revocable and scoped, but it is a real option and this section previously wrote it off by
-claiming no frontend change could help.
+the browser, on a user gesture, for permission to send its own unpartitioned first-party cookies,
+and Safari and Chrome both implement it. Note what the grant is and is not. It lets the frame's
+requests carry that cookie; it does not make the cookie script-readable, and the JWT cookie is
+`HttpOnly` in any case, which is the same point the OAuth paragraph above makes.
+
+It is also not available to remark42 as the flow stands, which is the part worth pricing. A browser
+denies the request outright when the embedded origin has no recent first-party interaction to
+grant against, and remark42 never acquires one: the reader interacts on the provider's origin, and
+the callback returns to the remark42 origin at a document whose first statement is `window.close()`
+under `?selfClose` in `iframe.ejs`. Nothing happens there that a browser counts as interaction.
+
+So the cost is not a permission prompt bolted onto the existing flow. Either the callback stops
+closing itself and collects a click first, or something else establishes first-party interaction on
+the instance's own origin before the frame ever asks. That is a change to the first-party
+experience, which is a different order of cost from the other two routes and has to be compared as
+one.
 
 The second is a server-mediated handoff, where the popup posts a one-time code to its opener and
 the frame redeems it over XHR. Two shapes exist there and they cost differently. If the redemption