`hey box --all` returns duplicate postings (one page appears twice)

[marek-aid]

hey box --all returns the same posting more than once. Reproducible on demand against two different boxes:

$ hey box 1672649 --all --json   # The Feed
1221 postings returned, 1191 distinct ids, 30 repeated
$ hey box 1672652 --all --json   # Paper Trail
1030 postings returned, 1000 distinct ids, 30 repeated

The repeated records are byte-identical, and the number of duplicates matches the page size exactly — hey box <id> --json without --all returns 30 postings, and each box comes back with exactly 30 extras. That looks like one page being fetched twice while walking next_history_url: an off-by-one on the cursor, or a boundary that shifts when a posting's active_at updates mid-fetch.

Why it matters beyond tidiness: any script that counts unread over-reports, and any script that collects posting ids to act on can submit the same id twice. My tooling now de-duplicates on id at the boundary, but the fix belongs here.

Imbox came back clean in the same run, so it may depend on box size or on activity during the fetch.

Possibly the same area of code as #109 — both boxes above also emit Showing N results. Pagination limit reached, so the --all walk is worth a look either way.

Against 0337cb5.

[marek-aid]

Follow-up: this isn't limited to hey box. As of 29ec034, the new hey attachments command shows the same duplication, and there the multiplier is exact and unmistakable:

$ hey attachments 2073766283 --json   →  "100 attachments in thread ..."  →   1 distinct id
$ hey attachments 2094548988 --json   →  "200 attachments in thread ..."  →   2 distinct ids
$ hey attachments 2085293247 --json   →  "300 attachments in thread ..."  →   3 distinct ids

Threads with 1, 2 and 3 real attachments report 100, 200 and 300. Every attachment is emitted exactly 100 times — once per page — and the records are identical, matching maxAdditionalPages = 100. So the page walk appears to re-read the same page rather than advancing the cursor, and both commands inherit it from the shared pagination helper.

All three of those responses also carry "notice": "Attachment discovery stopped after 100 pages of thread messages", which is the giveaway: these threads have one or two messages, so there is no reason for the walk to reach 100 pages at all.

One more symptom that may be the same root cause: hey attachments 2090164742 returns 0 attachments for a thread whose message body explicitly says an attachment is enclosed ("W załączeniu przesyłamy noty odsetkowe"). Discovery hit the 100-page ceiling before reaching the file, so a real attachment is invisible rather than merely duplicated — a false negative rather than a false positive.

Consumer impact is the same as for box: any script that counts, or that collects ids to act on, is wrong by a factor of 100 unless it de-duplicates defensively.