WalletCatchUpCue class sealed

The catch-up presentation truth (#380) — SHOULD the wallet surface explain an empty/partial balance + history as "still filling in", and with which copy. The banner, the activity empty-cue, and the swap "Available" line all derive from this ONE provider.

WHY a derived provider over the controller state alone: the controller is process-lifetime memory, but the misread it exists to prevent (review P1 #4 — a user watching their history "vanish" unexplained through an hours-scale catch-up) survives a process death (app update / LMK kill mid-catch-up) and a failure-notice dismiss. So the cue re-derives from the two DURABLE signals the wallet itself carries (the stamp is the same one the boot probe's prior-activity check trusts):

• lastSynced == null — this wallet's data DB has never completed a sync pass. The rescan rebuild clears the stamp by design and it stays null until the first reached-tip, so it is precisely "balance/history not yet whole". A restore's first catch-up and a brand-new wallet's brief first scan honestly qualify too (their balance/history are equally still filling in), so they deliberately share the cue. RESOLVED #357 (post-ship fix): the converse over-explanation ("synced-before yet lastSynced == null") is carried by the durable everSynced flag, which the core sets at reached-tip and CLEARS on a rescan (its aux row resets like sync_stamp — everSynced is the DURABLE proved-tip latch, and that latch resets on a rescan). So everSynced == true unambiguously means "reached tip since the last rescan ⇒ balance complete": suppress the cue (fixes the swallowed-stamp / pre-#317 / offline-relaunch over-explanation). A rescan REBUILD clears everSynced, so it shows the cue for its whole catch-up — including offline after a process death, the "did I lose funds?" panic window a first-cut everSynced && !scanning gate wrongly suppressed. everSynced == false (never synced, or post-rescan rebuilding) always shows the cue below tip.
• the sync status is below the tip (anything but SyncStatus_UpToDate: scanning, connecting, offline, stalled all keep the explanation up — an offline relaunch mid-catch-up still shows an emptied wallet).

Reached-tip clears BOTH signals on the same edge that clears the controller (the live status flips to up-to-date; the snapshot re-read stamps lastSynced). The walletSyncedTipProvider latch backstops the gap between those two: the snapshot re-read is owned by widget/resume listeners, so a busy-DB re-read fault — or a host that mounts only the swap surface — can retain a stale null stamp past the tip, and the next routine scan/offline sample would resurrect the cue over a FINAL balance. A tip this session already PROVED stays proved through routine re-scan windows, so the cue never flaps back. The controller state stays the intra-session FAST PATH because it carries the RescanTarget (the banner names what the user chose); the durable arm necessarily renders generic copy — the choice does not survive a relaunch.

Implementers

• WalletCatchUpNone
• WalletCatchUpRebuilding
• WalletCatchUpSyncing

Properties

hashCode → int

The hash code for this object.

no setter, inherited

runtimeType → Type

A representation of the runtime type of the object.

no setter, inherited

Methods

noSuchMethod(Invocation invocation) → dynamic

Invoked when a nonexistent method or property is accessed.

inherited

toString() → String

A string representation of this object.

inherited

Operators

operator ==(Object other) → bool

The equality operator.

inherited