feat(ui): show a loading state while transaction history loads

[QuantumExplorer]

Problem

On launch the home feed rendered "There are no transactions to display" until the first reload finished.

HomeView keyed that copy on viewModel.txItems.isEmpty alone — but txItems is empty in two very different situations: while the initial load is still running on the worker queue, and when the wallet genuinely has no history. Treating them the same meant every cold launch briefly asserted the wallet was empty before that was known, which reads as data loss on a wallet that actually has transactions.

Fix

HomeViewModel gains hasLoadedInitialTxItems, published on the main thread and set when the first full reload publishes its results. The feed shows a spinner + "Loading transactions" until then, and falls back to the empty-state copy only once an empty result is actually established.

Deliberately kept separate from the existing private hasCompletedInitialLoad: that one guards reload/incremental-update sequencing on the worker queue, is not published, and is not main-thread-confined, so it can't drive a view. Its behaviour is untouched.

Behaviour details

• Network switch resets the flag. That path clears the feed and reloads the new network's history from scratch — the same "loading, not empty" situation as a cold launch, so it gets the same treatment rather than briefly claiming the new network has no transactions.
• Ordinary refreshes never clear it, so the spinner does not flash on incremental updates once the first load has landed.
• A wallet with genuinely no transactions still ends at the same empty-state copy, just one load later than before.

Verification

dashpay scheme builds clean (arm64 simulator).

Note this branch is cut from develop, which is currently red — see #925, which fixes an unrelated #923/#924 merge collision. Building this branch locally needs that fix (or merge #925 first); the change here is independent of it.

Not visually confirmed on-device: the simulator is PIN-gated, and the state is transient by nature — it appears between launch and the first reload completing.

[coderabbitai]

Warning

Review limit reached

@QuantumExplorer, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 16 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: 41fe963d-4746-45fd-902c-28a1941af9b5

📥 Commits

Reviewing files that changed from the base of the PR and between 86301f0 and 077f855.

📒 Files selected for processing (3)

• DashWallet/Sources/UI/Home/Views/HomeView.swift
• DashWallet/Sources/UI/Home/Views/HomeViewModel.swift
• DashWallet/en.lproj/Localizable.strings

---

_{Comment @coderabbitai help to get the list of available commands.}