Backend asks blocking iOS parity — A8, A9, A11, A12 (+ A10 docs)

[Adron]

Part of #44 · Backend changes needed in ~/Codez/interlinedlist (the Next.js app). No iOS work
here beyond consuming them; each item names what it unblocks.

---

A8 — GET /api/user/{username}/messages ignores Bearer 🔴 one-line fix, no client work

The route resolves the viewer with session-only getCurrentUser(), so a Bearer client is
anonymous on a profile wall. Live-proved: the response is byte-identical with and without a
valid token.

Consequences on iOS:

• dugByMe is always false on a profile wall, so a post's dig state flips between the feed and
  the same post on the author's profile.
• The mutual-block filter never applies to the wall endpoint.

Ask: switch to getCurrentUserOrSyncToken.

---

A11 — no collaborator-scoped document listing 🔴 blocks a shipped web feature on iOS

The web lists documents shared with you (app/documents/layout.tsx → getSharedDocuments(user.id)
→ components/documents/SharedDocumentsList.tsx), but the data is server-rendered — there is no
API route, so no mobile client can reproduce it. Lists already have GET /api/lists/watching;
documents have nothing.

Ask: add GET /api/documents/shared-with-me (or GET /api/documents?scope=shared) returning the
existing getSharedDocuments() shape — { id, title, role, updatedAt, isPublic, owner } —
authorized with getCurrentUserOrSyncToken.

---

A9 — inbound email-invite acceptance is session-only 🟠

GET/POST /api/lists/invite/{token} and /api/documents/invite/{token} use getCurrentUser. iOS can
send invites (ShareInvitesSheet) but an invited iOS user cannot accept in-app — the deep link
has to bounce out to the web and back.

Ask: accept Bearer on both.

---

A12 — undocumented surfaces 🟡

No /help/api/* page exists for: /api/lists/watching, /api/lists/{id}/contributors,
/api/dm/conversations, /api/limits, /api/messages/{id}/reply-counts,
/api/organizations/{id}/users.

Ask: document them. reply-counts especially — its name reads like in-app reply counts, but it
returns cross-post reply counts from Bluesky/Mastodon/LinkedIn/X; that misreading already made it
into our own planning docs.

---

A10 residual — AI docs still describe BYO-key 🟡 docs only

/help/ai and /help/api/ai-integration still say the user brings their own provider key. The
product shipped as a subscriber entitlement on the app's server-side key
(lib/ai/resolve-provider.ts; live /api/ai/status returns providers:["anthropic"] for an account
with no keys). iOS #43 was built against the deployed behaviour, not the docs.

Ask: update both pages, and drop hasOpenaiApiKey / hasAnthropicApiKey / hasGeminiApiKey from
GET /api/user if they are now vestigial.

---

Checklist

• A8 — Bearer on the profile-wall messages route
• A11 — documents shared-with-me route
• A9 — Bearer on invite acceptance (lists + documents)
• A12 — /help/api/* pages for the six undocumented routes
• A10 — correct the AI docs; remove the vestigial key flags