feat: add wallet-scoped hardware wallet activities

[ovitrif]

Context

Bitkit Android is adding Trezor hardware-wallet UI in synonymdev/bitkit-android#998. The Android subtask synonymdev/bitkit-android#1029 needs Core support so hardware-wallet watcher transactions can reuse the normal activity stack: stable activity detail loading, inputs/outputs, tags, unified activity lists, and cleanup when a paired hardware wallet is removed.

Today Android has to keep hardware-wallet watcher activity outside the Core activity DB, manually merge it with Core-backed activity lists, sort/filter/paginate in app code, and fall back on reduced detail behavior. This should move into Core so Android and iOS can share the same activity behavior.

Keep this simple: walletId can be an opaque persisted identifier for a wallet, including a randomly generated id supplied by the app. It does not need to be deterministically derived from a descriptor or Trezor public material in this task. Apps own hardware-wallet metadata, backup/restore, and reattach behavior; Core only needs to preserve and operate on the caller-provided walletId.

Scope

Add wallet-scoped activity support to Bitkit Core.

Activity storage

Add a walletId field to activity records so Core can distinguish activity belonging to different wallets.

Requirements:

• Existing Bitkit wallet activity should keep working with minimal migration, e.g. walletId = null, a default wallet id, or another simple backward-compatible representation.
• Hardware-wallet activity should be stored with the caller-provided walletId.
• Activities from different wallets must not collide when they share the same txid.
• Returned activity records should include enough wallet/source metadata for clients to render hardware-wallet styling and navigate to the correct detail flow.

Activity APIs

Expose binding APIs that support both per-wallet and unified activity usage:

• Upsert hardware-wallet watcher activity with a walletId.
• Query activities for one walletId, e.g. a hardware-wallet detail screen.
• Query the normal all-activities feed with Bitkit wallet activity and hardware-wallet activity in the same result set.
• Sort the unified activity feed after combining wallet scopes so limit/pagination returns the true latest activity across Bitkit and hardware wallets.
• Preserve walletId on returned activity records.
• Delete all activity/details/tag metadata for one removed hardware-wallet walletId.

Existing-style activity filters should continue to work on the unified list where applicable: filter, tx type, tags, search, date range, limit, and sort direction.

Details and tags

Hardware-wallet activity should reuse normal activity detail and tag behavior.

Requirements:

• Activity Detail can load transaction inputs and outputs for hardware-wallet transactions using the configured Electrum/electrs backend.
• Tags can be added/removed on hardware-wallet activities through the same user-facing behavior as normal activities.
• Tags and other mutable metadata must not leak between wallets when two wallet-scoped activities share a txid.
• Cleanup for a removed walletId should delete scoped activity metadata without deleting data still needed by another wallet's activity.

Watcher ingestion

Support converting hardware-wallet watcher history into Core on-chain activities under a supplied walletId.

Requirements:

• Multiple account/address-type watchers under the same walletId should merge into one visible activity per transaction where appropriate.
• A transaction seen by both P2WPKH and Taproot watchers for the same hardware wallet must not create duplicate visible activity rows.
• A transaction that also belongs to Bitkit's main wallet must not overwrite or corrupt the main wallet activity/details/tags.

Acceptance criteria

• Core can persist and return activities with walletId metadata.
• Clients can upsert hardware-wallet activities with an opaque walletId.
• Existing Bitkit wallet activity behavior remains backward compatible.
• The all-activities query can return Bitkit wallet activity and hardware-wallet activity in one sorted list.
• Unified list filters, sorting, limits, and pagination behave consistently after combining wallet scopes.
• Per-wallet queries return only activity for the requested walletId.
• Same-txid activity can exist for different wallets without collisions or metadata leaks.
• Hardware-wallet activity details include transaction inputs and outputs when available from the configured Electrum/electrs backend.
• Tags work for hardware-wallet activity and remain scoped correctly.
• Removing a hardware wallet deletes Core activity/details/tag metadata scoped to that walletId without affecting other wallets.
• Tests cover opaque walletId storage, unified list sorting/pagination, per-wallet queries, same-txid collision isolation, tag behavior, detail cleanup, and FFI/binding exposure.