fixup! docs: webkeys — ids as bearer capabilities, kept out of URLs

The cache page now follows the paper's form (fragment + skeleton page),
with the XHR replaced by a Cap'n Web call taking the key in-band.

Generated-by: Claude Opus 5.5

docs/webkeys.md

@@ -78,9 +78,13 @@ fragment and the pattern got its standard form.
   minted by `newUniqueId()`, never derived from anything; all the
   authority, none of the log-trail
 - diigo-cache's ids are already webkeys in substance (bearer secrets);
-  the honest deviations, both known: keys travel in **POST bodies**
-  rather than fragment+XHR — same leak profile, simpler under a
-  form-driven UI with no skeleton page; and a hash of the id would
+  the cache page now follows the paper's form — `/cache/#<key>`, a
+  skeleton page, its script passing the key to the server — with the
+  XHR replaced by a [Cap'n Web](https://github.com/cloudflare/capnweb)
+  call that takes the key *in-band*, as a method argument
+  (`api.cache(key)`), returning a capability. The forms elsewhere still
+  carry keys in **POST bodies** (same leak profile as the fragment). A
+  hash of the id would
   stand in wherever log-correlation is wanted (the swissHash
   discipline; `shashKey`, whose prefix is also the on-screen
   fingerprint). The bug that prompted this note: a cache id briefly