Fix repeat listens being silently dropped, and rate-limit handling

[taurheim]

The bug

Last.fm keys a scrobble on (user, artist, track, timestamp) and silently discards any repeat of that tuple. It still returns accepted=1, ignored=0, so the loss is undetectable from the response. This is undocumented — I verified it experimentally against the live API (three scrobbles, two distinct timestamps, two plays landed).

reTagOldListens assigned the same Date object to every play moved into the 14-day window. So if you listened to a song five times, four of those were destroyed.

That path runs whenever "Scrobble tracks older than 2 weeks" is ticked: 300 of 386 parses, 80 of 119 people over the last 60 days.

Separately, scrobblePlay discarded the API response, so scrobbles Last.fm explicitly did report as ignored were counted as successes.

The fix

Timestamps for re-tagged plays are allocated at send time from a cursor, not baked in at parse time:

reTagCursorSec = min(nowSec, max(reTagCursorSec + 1, nowSec - RETAG_BACKFILL_SECONDS))

Send-time allocation rather than parse-time matters for two reasons beyond uniqueness:

• Spreading by real track duration only fits ~5,700 tracks in the 14-day window. At 1s spacing, 80,000 fits in 22 hours.
• Absolute timestamps baked in at parse time expire. A queue saved today and resumed three weeks later would be rejected wholesale with ignore code 3.

The cursor persists as a high-water mark (lastReTagTimestampSec) so a resumed run can't reuse seconds an earlier run already sent, and is allocated once per track, not once per attempt — if the original request reached Last.fm and only the response was lost, an identical resend is deduplicated away, whereas a fresh second would become a phantom play in the user's library.

scrobblePlay now returns a ScrobbleResult. Parsing defaults to accepted on an unrecognised shape, so a surprise response can never invent failures.

Also in this PR

• Rate limiting reworked (RateLimitTracker): rolling window of send timestamps with a limit learned adaptively from observed 429s, escalating backoff (5/15/30 min), then an honest give-up-and-save. The old flat 1-minute-forever retry produced 33 recoveries across 2,135 observed rate limits, median 130 minutes — two users sat through 200+ consecutive retries watching a countdown that was never going to work.
• Resume was silently broken: a 2-second delayed emit in AuthenticateStep undid a resume the user had already started.
• Completion telemetry: original_total_tracks, total_succeeded, completion_pct, is_resumed, previously_scrobbled. Completion was previously measured against the remaining chunk, which shrinks on resume — real cases went 81,313 -> 573 and 9,924 -> 40, so a barely-started import looked nearly finished.
• Migration for in-flight users: a saved session whose timestamps are >=90% identical (across >=20 tracks) is re-stamped on load.
• filterDuplicates skips re-tagged listens, whose provisional timestamps would otherwise be matched against real listening history and silently drop import rows.

Testing

36/36 Playwright tests pass, including four new ones covering distinct timestamps, ignored-scrobble accounting, and retry idempotency. Lint 0 errors, build clean.

Known unfixed (pre-existing)

• failedIndices is always written empty, so failed tracks are never retried on resume.
• total_succeeded is an upper bound: re-scrobbling history a user already has is indistinguishable from a fresh play.