fix: nameless-account parity on the You and Chats tabs, and add-money from a held balance

[bmc08gt]

Three iOS→Android parity fixes for an account that hasn't set a display name, plus an
add-money milestone that never completed.

fix(balance): complete the add-money milestone from a held balance

The "Add Money" milestone only cleared on a deposit event, so an account that arrived
with a balance already held — restored on another device, or funded before the milestone
existed — was stuck being told to add money it already had. It now completes off the held
balance itself, matching iOS.

fix(tipping): keep the Chats tab on the list for a nameless account

The Chats tab was hidden until the account had a display name, which is backwards: a
nameless account can still receive DMs and had no way to read them. iOS shows the tab
unconditionally. The name gate stays on tipping itself, where it belongs.

fix(menu): prompt a nameless account to claim its tip card on the You tab

The You tab modelled the tip card as a nullable, so tipCard == null meant both "still
resolving" and "this account has no display name" — YouHeader opened with
if (card == null) return and drew nothing for either. A nameless account got a page with
no card, no prompt, and no way to claim one from the tab that owns it.

Replaced with an Unknown / Unclaimed / Claimed tri-state. Unclaimed draws the card
the account would have, frosted out behind the claim prompt and its CTA into display-name
entry, mirroring iOS YouScreen.setupPrompt:

• The stand-in is the account's real scannable payload with the card's own fill turned off,
  so the 8% ground is what gets blurred. A placeholder name stands in for the empty one so
  the blurred name line has the width a real card's would (iOS placeholderName).
• Frosted with haze's foreground blur rather than Modifier.blur. Haze draws the blur
  as a layer in front of its source, so the effect carries an opaque backgroundColor —
  the flattened card ground — or the sharp code would read straight through its own
  frosting. Below API 31 (minSdk is 29) haze can't blur, and its scrim fallback draws
  nothing unless told to, so a fallbackColorEffect tint covers the same ground. Film
  grain is off: over a scannable figure it reads as noise in the code, and iOS frosts
  with a plain blur(radius: 12).
• The tip link and the Share / Download tiles are absent while unclaimed, expansion is
  disabled, and the Sharesheet preview is no longer warmed for a card that can't be shared.
• Resolution is gated on AuthState.Ready, so a named account — which restores its cached
  profile before auth completes — never flashes the prompt.
• Spacing follows iOS's conditional gap: 48dp between the unclaimed stand-in and the first
  settings row versus the claimed card's 19dp
  (.padding(.top, displayName == nil ? 48 : 19)). The claimed card pays part of its
  clearance in the Share / Download tiles the unclaimed state doesn't draw. Row insets
  already match — ListItem pads grid.x5 = 25dp, the same as iOS's rowInsets.

test(menu): preview the unclaimed tip card's API 29/30 blur fallback

Haze only blurs on API 31+, and minSdk is 29 — below that it falls through to a scrim
delegate that draws nothing unless given a colour effect. That makes the stand-in's
fallbackColorEffect the only thing between an API 29/30 device and a fully legible tip
code behind the claim prompt, and nothing exercised the branch.

Haze's own blurEnabled gate is now a parameter on UnclaimedTipCardPrompt, defaulted to
HazeBlurDefaults.isBlurEnabledByDefault() so app code is unchanged, with a preview pair:
the blurred API 31+ rendering and the scrim fallback an older device draws. The fallback
preview is the one that matters — if the tint ever comes off, the code shows through it.