@mentions: resolve end-to-end via a token-auth source of user SGIDs #2

Problem

The @mention patch (ported to v4 in #1, branch mention-resolution-v4) is structurally complete and the post path works — posting a comment/description with a valid ActionText mention attachment via the API token stores it intact and notifies (proven live; see #1 comment). The only missing piece is obtaining each user's SGID with the API token.

Why it's blocked

• The CLI fetches mentionables from /{account}/prompts/users with Accept: text/html. The Fizzy API now rejects Accept: text/html globally -> 401 "HTTP Token: Access denied" (even on the known-good /users endpoint).
• With Accept: application/json the token authenticates but /prompts/users returns 500 (HTML-only Lexxy view, no JSON representation).
• The JSON API exposes user id but not sgid. The SGID decodes to gid://fizzy/User/<id>?expires_in (non-expiring), signed by the server secret_key_base — so it cannot be forged client-side.

Consistent with mentions having worked previously and a server-side change to API content-type handling breaking only the fetch step.

Acceptance

• fizzy comment create --card <test> --body "@Wayne hi" stores content-type="application/vnd.actiontext.mention" (not plain @Wayne) and notifies — no Unauthorized warning.
• e2e test asserts the stored HTML contains the attachment.

Options (in preference order)

1. Upstream ask (cleanest): request basecamp add sgid to the user JSON, or expose a JSON mentionables endpoint reachable with the API token.
2. Harvest + cache: scrape SGIDs from existing content into a local cache. Works only for already-mentioned users — partial.
3. Web-session auth: have the CLI hold a Fizzy session cookie for /prompts/users. Heavier; against the API-token-only design.

Depends on the v4 sync + ported patch landing on master (#1).