return-group.spec.ts flaky: History Scan doesn't reliably surface recent entries

## Problem

`web/e2e/return-group.spec.ts`'s final assertion (a returned item's condition note shows up on the dashboard's History tab) fails intermittently in CI, timing out even with a 45s/5s-interval poll budget.

## Root cause

Confirmed via direct DynamoDB inspection during GH-356's e2e-flakiness work: the write path is correct — the condition note is reliably persisted to `history-alpha` (`ItemTable.createHistoryEntry`). The failure is purely on the read side:

- `ListHistory` (`ts-code/src/api/ListHistory.ts`) defaults to a 25-item page (`DEFAULT_PAGE_SIZE = 25`), read via an unordered `Scan+FilterExpression` (`scanUntilLimit`).
- DynamoDB `Scan` does not return items in any guaranteed order (not chronological).
- The shared e2e fixture item (`RMS_TEST_ITEM_ID`) has accumulated a very large number of history entries from extensive repeated CI runs, so a freshly-written entry has a low chance of landing in the first unordered 25-item page the dashboard's History tab reads.
- Separately, `history-alpha` (like the rest of this repo's tables) is provisioned at 1 RCU/1 WCU (see root `CLAUDE.md`), so repeated Scans against a now-large table intermittently throttle (`ProvisionedThroughputExceededException`), compounding the problem.

## Suggested fix directions (not decided)

- Add a secondary sort/index so `ListHistory` can return newest-first instead of arbitrary Scan order (would need a GSI on `history-alpha`, keyed by `borrower`/`itemId` + `timestamp` — today there's no GSI on this table, only base-table Scans).
- And/or: clean up `history-alpha`'s accumulated entries for the shared e2e fixture item (a one-off maintenance script, paced per this repo's 1 WCU-table write-pacing convention — see `ts-code/scripts/migrate-353-stable-ids.ts` for the established pattern) so the working set stays small enough for a first-page Scan to reliably include recent writes.
- Do not fix this by raising table capacity — the user has flagged that account-wide DynamoDB capacity (currently 7 RCU/7 WCU total across 7 tables, out of the 25/25 free-tier ceiling) needs to stay low headroom-wise for `beta`/`master` environments planned later (see "Branching and environment promotion" in root `CLAUDE.md`).

## Context

Found while stabilizing e2e CI for GH-356 (PR #369, merged via admin override past this one flaky check — every other check, including the rest of the e2e suite, unit tests, coverage, and CodeQL, was green). No code changes have been made for this issue yet.