- inbox.go: precise wording on legacy cap semantics — it's 200 distinct
*issues* (newest entry per issue), not 200 raw rows. Same for the
unread-badge degradation note. Add structured slog at the legacy
entrypoint with X-Client-Platform / X-Client-Version so we can track
install-base on the legacy contract (cf. MUL-1795 A1 follow-up).
- client.ts: listInbox always sends ?limit, defaulting to 50 when no
param is passed. The server identifies legacy callers by the absence
of every pagination param; if a future filter (e.g. ?status=unread)
ships without a default limit, it would otherwise fall into the
legacy 200-cap branch by accident.
- schemas.ts: comment why dedup transform's localeCompare on created_at
is correct (RFC3339 strings are lexicographically ordered).
- inbox_test.go: fetchInboxLegacy now asserts the response body starts
with '[' so a future refactor that wraps the legacy body silently
cannot pass these tests. Add TestListInbox_LegacyDedupBeforeCap to
pin the dedup-then-cap interaction (250 same-issue items collapse
to 1 row, not fill the 200 cap).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
1141981eeb