fix(fullnode): make witness/rescan progress work on the real daemon

Verified by running the app against a live node and watching a real rescan. Three
issues that only surfaced at runtime:

- Wrong RPC name: this daemon (hush/komodo) exposes the runtime rescan as
  "rescan <height>", not bitcoin's "rescanblockchain". runtimeRescan() and
  RPCClient::rescanBlockchain() used the bitcoin name and failed with "Method not
  found" on every node. Corrected to "rescan".

- Witness/rescan progress never surfaced during a rescan: the daemon-output parser
  that drives it was gated behind rpcConnected, but a heavy rescan holds cs_main so
  getinfo times out and the RPC reads disconnected — silencing the parser exactly
  when it's needed. The parser reads the daemon's stdout pipe (no RPC), so it now
  runs whenever the daemon process is alive. It also now parses INLINE on the main
  thread instead of via fast_worker_, so it can't be starved when the worker is
  blocked on a getrescaninfo call (which waits on cs_main during a witness rebuild).

- Witness rebuild has TWO sub-phases with different scales — the initial-witness
  pass ("Setting Initial Sapling Witness for tx <hash>, <i> of <N>") and the cache
  walk ("Building Witnesses for block <h> <frac> complete, <n> remaining"). Tracking
  them with one monotonic value pinned the bar at the initial pass's ~100% through
  the whole cache walk. They're now tracked as distinct phases (witness_phase) with
  their own monotonic progress and labels ("Setting witnesses" vs "Rebuilding
  witnesses"), so neither resets/bounces and the long phase shows real movement.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

src/data/wallet_state.h

@@ -127,12 +127,18 @@ struct SyncInfo {
     float rescan_progress = 0.0f;  // 0.0 - 1.0
     std::string rescan_status;     // e.g. "Rescanning... 25%"
 
-    // Sapling note witness rebuild (the phase after a rescan/zap where the daemon rebuilds the
-    // wallet's note witnesses, logged as "Building Witnesses for block ..."). Tracked separately
-    // from rescan_progress because it's a distinct, often-long phase with its own progress.
+    // Sapling note witness rebuild — a distinct, often-long phase after a rescan/zap. The daemon
+    // reports it in TWO sub-phases with different signals, so we track which is active:
+    //   1 = initial pass ("Setting Initial Sapling Witness for tx <hash>, <i> of <N>") — progress
+    //       is distinct-txs-witnessed / N (the <i> bounces, so it can't be used directly).
+    //   2 = witness-cache walk ("Building Witnesses for block <h> <frac> complete, <n> remaining")
+    //       — progress derived from how far "remaining" has fallen from its per-phase peak.
+    // The two are sequential with different scales, so progress is NOT carried across the boundary
+    // (that would pin the bar at the initial pass's ~100% through the whole cache walk).
     bool building_witnesses = false;
-    float witness_progress = 0.0f;  // 0.0 - 1.0
-    int witness_remaining = 0;      // blocks left to build witnesses for (0 if unknown)
+    int witness_phase = 0;          // 0 none, 1 initial-witness pass, 2 witness-cache walk
+    float witness_progress = 0.0f;  // 0.0 - 1.0, within the current sub-phase
+    int witness_remaining = 0;      // blocks left in the cache walk (0 if unknown / phase 1)
 
     bool isSynced() const { return !syncing && blocks > 0 && blocks >= headers - 2; }
 };