perf(wallet): stop the login spinner waiting on three network races

[bmc08gt]

On a fresh login or account create the wallet tab draws nothing while
isAwaitingTokens || isAwaitingActivity (WalletScreenContent.kt:86). That is an
AND over three independent network races, none of which start before
AuthState.Ready, and each was slower than it needed to be. iOS seeds its wallet
from the session synchronously and gates only the tutorial card, which is most of
why it feels quicker.

Three changes, no behaviour dropped.

The balance fetch no longer idles for two seconds

tokenUpdater.poll(startIn = 2.seconds) is the only thing that fetches balances
after login — TokenCoordinator.onUserLoggedIn just hydrates Room, which is empty
on a new account — so the head start was two seconds of spinner spent deliberately
idle.

It could also be worse than two seconds. onAppInForeground fires twice at login,
once from the transition into AuthState.Ready and once from ON_RESUME, and
NetworkUpdater.poll stopped and relaunched unconditionally: the second edge
cancelled the in-flight fetch and re-served startIn, pushing the first fetch of a
fresh session further out. poll now uses its previously unused key parameter as
an identity and leaves an equivalent running loop alone. stop still resets on
background and logout, and NetworkUpdaterTest covers both.

The tutorial waits on chat hydration; the rest of the tab does not

onboardingItems stayed null until hasEverTipped() could answer, and that answer
waits on the per-chat backfill behind ChatHydrationState — a wait that scales with
how many conversations the account has. The milestone combine now always emits,
carrying isTipMilestoneResolved to say whether the tip half can be believed. Only
isNewUserTutorialComplete reads that flag, so "Scan a Tip Card" is still never
drawn as outstanding to someone who has already tipped, while the balance, the card
deck and the action tiles draw off state the app already holds.

The login feed seed is 25 rows, not 100

The count only bites on a cold cache; with anything cached fetchSinceLatest pages
forward from the newest row and takes whatever has happened since. So it is really
how much history a fresh login waits for before the wallet can draw, and the wallet
previews three rows. 25 still covers the history screen's first page, which pages at
20, and leaves the rest to that screen's own paging. The catch-up is guarded against
the repeated foreground edge as well, so the second one joins the in-flight fetch
instead of duplicating it.

Out of scope

The sequential per-chat backfill behind CatchUpComplete is untouched, and it is
still the long pole for an account with many conversations. This takes the wallet off
it rather than fixing it.