wallet: resolve the autoshield destination at startup

pwalletMain->autoShieldAddress was only ever written by a round running in the
current process, so on any node without an explicit -autoshieldaddress,
z_autoshieldstatus reported an empty destination from startup until the first
round fired. disabled_reason was empty on that path too (rpcwallet.cpp), so the
RPC showed autoshield true, running false, no address and no explanation -- the
exact silent state z_autoshieldstatus was added to eliminate. On a restored
wallet, which pre-derives the whole -mnemonicsaplinggap window and therefore
always has an in-gap account to pick, the answer was known at startup and simply
not computed.

Split the read-only half of resolveDestination into a free function shared with
init: the configured override if set, else the lowest in-gap account
m/32'/coin'/i' the wallet already holds. init calls it once when autoshield is
enabled and no explicit address was given.

It deliberately does not generate a key. Deriving a fresh sapling account as a
side effect of populating a status field would mutate the wallet to make an RPC
prettier, so step 3 of resolveDestination -- the generation path, which must stay
inside the operation where an unlocked wallet is already established -- is left
where it was. A brand-new wallet holds nothing in-gap, so the field stays empty
there and disabled_reason now says why instead of being blank.

Behaviour is otherwise unchanged: same derivation, same lowest-index-wins rule,
same refusal to trust CKeyMetadata, same caching for the life of the process.

Verified on an isolated regtest chain, 12/12:
  fresh wallet      -> address "", reason "no destination resolved yet; one will
                       be derived from the HD seed on the first round"
  after one round   -> address set, reason empty
  after RESTART     -> address visible with NO block mined since (height 12 both
                       sides), and z_listaddresses still holds exactly 1 address,
                       so init derived nothing
  -autoshieldaddress-> still overrides the derived destination, and the round
                       shields into it

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

src/wallet/asyncrpcoperation_autoshieldcoinbase.h

@@ -14,6 +14,26 @@
 // Default fee for automatic coinbase-shielding transactions
 static const CAmount DEFAULT_AUTOSHIELD_FEE = 10000;
 
+// Sentinel for "not a derived account" (i.e. the configured -autoshieldaddress).
+static const uint32_t AUTOSHIELD_ACCOUNT_NONE = UINT32_MAX;
+
+enum class AutoShieldDestStatus {
+    Resolved,        // destOut/destStrOut are set
+    NotFound,        // no in-gap account held yet; the operation will derive one
+    InvalidOverride, // -autoshieldaddress is set but is not a Sapling address
+    NoSeed,          // no HD seed available (e.g. locked wallet)
+};
+
+// Resolve the auto-shield destination WITHOUT mutating the wallet: the configured
+// -autoshieldaddress if set, else the lowest in-gap seed-derived account the wallet
+// already holds. It deliberately does NOT generate a key, so init can call it purely
+// to answer "where will this send?" -- deriving a fresh account as a side effect of
+// populating a status field would be wrong. The operation's own resolveDestination
+// falls through to generation when this returns NotFound.
+// Caller must hold cs_wallet.
+AutoShieldDestStatus ResolveAutoShieldDestinationReadOnly(
+    libzcash::SaplingPaymentAddress& destOut, std::string& destStrOut, uint32_t& accountOut);
+
 // A periodic, wallet-local operation that drains matured *transparent* coinbase
 // UTXOs into a wallet-owned Sapling z-address in size-bounded batches. It is the
 // automatic sibling of the manual z_shieldcoinbase RPC and mirrors the dispatch