[iPeluwa]

Stacks on #124 (that one flushes after a reap; this covers the case it can't see).

Problem

A settled session is submitted by its clean end. When those flushes all fail for a window — a burst of endcards meeting the rate limiter is enough — nothing ever retriggers: there is no later clean end until the user next closes a session, and desktop sessions can stay open for days. Real incident: nine finished sessions carrying 133 commits sat unsubmitted for ~22 hours; the leaderboard never moved.

#124 narrows this for reaped sessions, but sessions that finalized cleanly and failed to upload have no trigger at all.

Fix

submitProgress already ticks onto the network every few minutes for a live shipped session. It now also runs flushPendingSubmissions on that tick (same throttle, same budget), so any live session — shipped or not — drains whatever settled work is stuck. An empty queue costs nothing: the flush resolves auth locally and returns before touching the network.

The momentum and signature early-returns now gate only this session's own in-progress submit; the queue drain runs first, so settled work goes out even when this session has nothing new to say.

Tests

test/flush-on-tick.test.mjs (3 cases): a due tick sends a settled session that missed its clean end; a tick inside the throttle window drains nothing; a shipped session whose signature is unchanged still carries the queue while its own submit stays deduped.

[iPeluwa]

Closing — keeping these fixes local rather than upstreaming. Thanks!