Add z_importkey and z_exportkey test

[oxarbitrage]

A new test for zcash/zallet#400

[oxarbitrage]

Handoff from zallet: extend this test for rescan-on-import (zallet #578 / #579)

Two zallet fixes need coverage here, both about importing into an already-running wallet (no restart) — which this test doesn't yet exercise:

• fix: reload sync engine viewing keys after key-adding RPCs zallet#579 (merged): imports now reload_keys(), so a key imported into a running wallet is scanned going forward.
• fix(rpc): rescan already-scanned range when z_importkey re-imports a known key with rescan=yes zallet#581 (Closes #578): re-importing an already-known key with rescan="yes" now rewinds the scan queue to re-scan the already-scanned range and find historical notes. Build/test against branch import-rescan-rewind-578 @ 38610e3.

This PR needs a rebase onto current integration-tests main anyway (idle since March; the harness / zallet RPC surface has moved). Proposed additions, all against a running zallet, asserting without a restart:

1. Existing key, rescan="yes" → re-scan (zallet #581 / #578). Fund a Sapling address; import the key with a birthday at/after the funding height so the note is initially missed; then z_importkey the same key again with rescan="yes" and an earlier startHeight. Assert the previously-missed note now appears. ← core #578 case.
2. New key, old birthday → historical note found (zallet #579 path). Fund an address, let the wallet scan past it, then z_importkey that key with an early startHeight. Assert the historical balance appears.

Determinism note: put birthdays well below the sync tip (>~100 blocks) so the re-queued range is serviced by the finalized-region scan loop — a birthday within ~100 blocks of the tip only re-scans once the chain advances past the steady-state window.

Once these land on export-import-key-test, PR #581 will carry ZIT-Revision: export-import-key-test so zallet CI runs them against the fix. (Branch name, not a SHA, so the reference survives the rebase.)

[oxarbitrage]

Also confirm: can imported keys be spent? (suspected separate bug)

Alongside the rescan tests above, while z_importkey is set up please also attempt a spend from the imported account — a code read strongly suggests it currently fails. The imported account is stored as AccountPurpose::Spending { derivation: None }, and the spend path only rebuilds authority from seed + ZIP-32 derivation, so z_sendmany bails before signing (z_send_many.rs:281); the stored Sapling key is never wired into the spend path.

After importing a funded key:

z_sendmany "<imported-sapling-addr>" '[{"address":"<dest>","amount":0.0001}]'

Expected (please confirm): errors with Invalid from address, no payment source found for address.

This is not part of #578/#581 (that's rescan-on-import) — it's a separate suspected bug: an imported spending key whose funds can't be spent. We want to confirm it empirically here before filing a zcash/wallet issue. If it fails as predicted, it's a clean regression bracket (assert-fails-now → assert-succeeds once fixed). If it unexpectedly succeeds, even better — flag it.