feat(userflags): surface the username minimum balance flag

[bmc08gt]

UserFlags gained username_min_balance upstream — the USDF amount, in quarks, a user must hold across all currencies before setting a username. This vendors the proto change and maps the field through to the domain model and the debug flag editor.

It gates the username claim flow whose service layer landed in #1320. That flow has no UI yet, so nothing reads this value so far.

Read-only, not overridable

Every other Fiat flag is overridable in the debug editor; this one isn't. The practical cost: exercising the claim gate locally means having the server send a non-zero value, since you can't force one from the editor.

ReadOnlyEntry holds a Boolean, so the amount goes in readOnlyTextEntries next to tipPresets, formatted with Fiat.FormattingRule.Truncated to match how WithdrawalFeeAmount renders.

Default is Fiat.Zero

The fee and price flags (newCurrencyPurchaseAmount, newCurrencyFeeAmount) default to Fiat.MAX_VALUE — for an amount the user pays, an unknown value should fail closed. This one is a minimum balance to hold, the same shape as minimumHolderValue, so it takes that flag's Fiat.Zero default instead.

Zero means an absent flag leaves the gate open and the server's INSUFFICIENT_BALANCE result stays the real enforcement, rather than hard-blocking a claim the server would have allowed. The tradeoff to be aware of: a silent mapping failure would look identical to "no gate configured."

The resemblance to minimumHolderValue stops at the default. minimumHolderValue is a per-mint threshold — TokenDiscoveryViewModel checks it against one token's balance — whereas username_min_balance is cumulative across every mint. Whoever writes the claim gate should compare it against the summed balance (LocalFiat.underlyingTokenAmount), not a single token's. The domain property carries that note in a comment.

CachedFlags needed the field too

UserFlagsCoordinator holds a @Serializable cache model whose toDomain() reconstructs the whole UserFlags, so it doesn't compile without the new field. It defaults to zero quarks so payloads cached before this change still decode — the read path does runCatching { json.decodeFromString<CachedFlags>(raw) }.getOrNull() ?: return, which discards the entire cached flag set on a decode failure. An undefaulted field would blank the flags on the first launch after upgrade.