fix(qortal): bound history recovery and expose partial accounting

[QuickMythril]

fix(qortal): bound history recovery and expose partial accounting

Qortal JNI history can exceed an embedding Core's native-call timeout while recovering historical recipients. Give connection and all outgoing recovery one shared five-second deadline, one attempt per transaction-hash candidate, and cancellation of unfinished futures. Synchronous database reads and transaction decoding remain outside that deadline.

Separate outgoing accounting from display amounts, whose fee semantics differ between send intents and historical net rows. Confirmed local spent inputs, attributed internal receipts, and an established fee provide an exact fallback; known zero remains distinct from unknown. Filter expired unmined intents using scanned height before applying the limit. Isolate dangling-scope checks from existing GUI transfer splitting.

Sapling and Ironwood builders can pad with outputs that do not recover under the wallet's keys. Do not infer that every missing output is padding, or require dummy outputs to decrypt to complete locally established accounting. For supported fully shielded transactions, derive the fee with the parsed transaction's checked fee_paid calculation after verifying its txid. Require no transparent inputs or outputs and no unsupported pool components. That fee completes confirmed, attributed restored-history accounting without a stored send intent, including custom and dust-adjusted fees. Raw fee evidence supersedes a conflicting stored fee and invalidates its old fallback; recompute only with the required local accounting. Retain positive unknown-recipient remainders.

Add the explicit typed JSON method qortal_list_transactions_partial through the existing JNI invokeJson bridge. It retains eligible rows with null unknown totals, separate default-fee estimates, available recipient metadata, completeness diagnostics, and unconfirmed state. Aggregate amount/fee fields use decimal strings. Pending or scope-uncertain rows without independent total evidence remain visible as incomplete; a recovered subtotal is not presented as an exact total.

Compatibility: existing list / qortal_list_transactions retain their strict response and can still reject unresolved pending or restored rows. Consumers must explicitly adopt the partial method to gain partial availability; a native update alone does not fix consumers that continue to call strict list. No command-table alias is required because the JNI JSON entry point already exists. Consumer integration must preserve null/estimated amounts, avoid inferring direction from an unknown amount, and count the fee once per transaction. Core/Home/Wallet consumer changes are outside this native PR. The integrated consumer stack has been deployed for local acceptance using the JNI artifacts built from this PR head.

The two commits separate deadline/accounting work from the explicit partial API. docs/qortal-handoff.md documents the behavior and limitations. No storage migration, generated bindings, Flutter source, signing behavior, or platform-specific source is changed. The existing payment-disclosure fixture is extended only under tests.

Validation: the full all-features Rust workspace suite passed 892 tests, with zero failures and 45 ignored. Final strict all-targets/all-features Clippy and formatting checks pass. All 20 targeted Qortal adapter tests pass, including real Ironwood builder padding and a shielded cross-pool fee fixture, Sapling dummy versus missing positive outputs, raw/stored fee disagreement, vin-only and vout-only guards, negative fees, txid mismatch, pending rows, scope, deadline/cancellation, expiry, and serialization. Independent final source review reports no remaining production blocker. Automated tests used synthetic fixtures. Flutter/platform checks were performed in CI. At head 6b19fb18, CI completed with 32 successful and 15 skipped jobs, including all five Qortal JNI platform packages. Following deployment of the matching native artifacts with the Core/Home/Wallet consumers, the wallet owner reported that the integrated application works as expected. This is owner-reported local acceptance, not exhaustive platform or funded-send validation.

[OswaldKardingson]

tACK