feat: load real transaction history in demo app

[j-kon]

Summary

• replace transaction history sample rows with active-wallet-backed data
• map BDK wallet transactions into demo-app history rows
• add a clear no-active-wallet state before loading transaction history
• keep widget tests lightweight by overriding wallet availability instead of creating real BDK wallets
• keep test-only fakes under the transaction feature test helpers

Context

Continues the transaction presentation scaffold from #62 by wiring the list/detail flow to active wallet transaction data instead of sample rows.

The production transaction repository still uses the BDK Dart API to read wallet transactions, while widget tests use fake repositories and a lightweight wallet-availability provider.

Verification

• dart format --output=none --set-exit-if-changed lib test example bdk_demo/lib bdk_demo/test
• dart analyze --fatal-infos --fatal-warnings lib test example
• dart test
• flutter analyze inside bdk_demo
• flutter test --no-pub test inside bdk_demo

Validation passed:

• root Dart tests: 22/22 passed
• bdk_demo Flutter tests: 181 tests passed
• no analyzer issues

Also confirmed:

• transactions_list_page_test.dart does not import package:bdk_dart/bdk.dart
• no widget test creates a real BDK Wallet
• production transactions_repository.dart still imports and uses BDK

[Shamsudeen12]

Hi @j-kon, nice work here

I noticed something. The transactionsControllerProvider isn't auto-disposed, so it outlives the TransactionsListPage and persists the data for the previous session. It gates on hasActiveWalletProvider, which is a boolean and switching from wallet A to wallet B through the Active Wallets screen (active_wallets_page.dart → activeWalletProvider.notifier.set(...)) leaves that provider at true, so the controller's build() never re-runs and the list keeps rendering wallet A's transactions under wallet B.

Steps to reproduce: load wallet A → open Transactions → Load Transaction History → switch to wallet B → reopen Transactions. It still shows wallet A's transactions; tapping one resolves against B's repository and 404s as "Transaction not found."

The sibling providers already handle this by keying off wallet identity, blockchain_providers.dart resets when activeWalletRecordProvider.id changes. Might be worth having the controller watch an activeWalletId (or ref.listen the record and reset) instead of a bool. Happy to be corrected if in-place switching isn't a supported flow.

[j-kon]

Thanks for the detailed. You were right that the transaction state was scoped only to wallet availability rather than the logical active wallet.

I updated the transaction list and detail flow to use the active wallet record ID. Switching from wallet A to wallet B now clears the previous wallet’s transaction state, and stale asynchronous results are ignored if the active wallet changes before loading completes.

I also added coverage for wallet switching so transaction list and detail data cannot leak between active wallets.

[Shamsudeen12]

Thanks @j-kon
Everything looks good from my end 🙌🏾

[Johnosezele]

tNACK e4c458c

Navigating to Transaction History on device throws:

setState() or markNeedsBuild() called during build. UncontrolledProviderScope … already building widget currently being built: TransactionsListPage

pls fix the rebuild + listen pattern, and add a widget coverage that mounts the list page with an active wallet so this can’t fail silently.