capsite: goal trees for a zotero cache and a social.coop cache

Both follow the diigo-cache pattern (webapp holds the credential,
read-only and minted narrow at the source; the cache serves a public
page). Zotero's versioned sync answers diigo's stale-head problem;
Mastodon's doesn't announce edits/deletes, so its tree carries that
as a design question.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

capsite-checklist.md

@@ -107,7 +107,9 @@ narrative.
         does re-mint mean a new cache? Prefer re-wire — durable ids.
   - [ ] **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).
+        item shape is diigo-specific): [the zotero goal tree](zotero-checklist.md).
+        The social.coop account is next after that:
+        [the social.coop goal tree](social-coop-checklist.md).
 - [ ] **webapp graduates from prototype** (optional; only if it earns it)
   - [ ] TODO(webapp): one canonical mint form — proxy-page (current) vs
         running webapp as the primary worker so its own port serves the
@@ -171,6 +173,8 @@ to every goal in this tree.
 
 ## Pointers
 
+- [the zotero goal tree](zotero-checklist.md) and
+  [the social.coop goal tree](social-coop-checklist.md) — the next caches
 - [the capsite notes](capsite-notes.md) — the original goal and the EmDash
   native-plugin wiring details
 - [docs/webkeys.md](docs/webkeys.md) — the Waterken URL-capability