What

Adds an {"includePending": true} option to the name_list RPC that includes the wallet's unconfirmed name operations from the mempool alongside its confirmed names. Default is false, so existing callers see no change.

Why

Today a wallet UI that wants "my names, current state" has to:

1. Call name_list for the wallet's confirmed names.
2. Call name_pending (now with mineOnly:true from rpc: add mineOnly to name_pending; fix optional ismine across static archives #585) for the wallet's pending name ops.
3. Merge them client-side, replacing any confirmed entry whose name has a more recent pending update.

Every Namecoin wallet UI ends up duplicating that merge logic. Even this repo's QT name table model (src/qt/nametablemodel.cpp) does the same dance:

confirmedNames = parent.walletModel->node().executeRpc("name_list", params, walletURI);
...
pendingNames = parent.walletModel->node().executeRpc("name_pending", params, walletURI);

With includePending:true the merge happens server-side, in the place that already has both pieces of data and the right locks.

Behavior

• Opt-in. Default includePending:false preserves the previous behavior byte-for-byte.
• When set, name_list also walks pwallet->mapWallet for unconfirmed wallet txs (depth <= 0) and emits an entry per name op.
• Pending entries are decorated with:
  • "pending": true
  • "op": either "name_firstupdate" or "name_update"
• A pending entry replaces any confirmed entry for the same name. The wallet's pending op is its more recent intended state, so a UI that respects the pending row matches what the chain will look like once the tx confirms.
• If multiple pending wallet txs touch the same name (e.g. an RBF chain that hasn't been pruned from the wallet), the one with the highest nOrderPos wins — i.e. the most recently created of the wallet's own pending txs.
• tx.isAbandoned() pending txs are skipped, mirroring how pwallet->mapWallet consumers usually treat them.

Schema notes

Pending entries have no canonical chain height, so the existing height, expires_in, and expired fields are omitted for them. The result schema now marks those three fields as optional. The output for confirmed entries (with or without includePending) is byte-for-byte unchanged.

The new pending and op fields are also optional and only appear on unconfirmed entries.

Companion changes

This PR is the third leg of three closely-related changes:

• rpc: add mineOnly to name_pending; fix optional ismine across static archives #585 (already open) — adds mineOnly to name_pending and fixes the underlying MaybeWalletForRequest/typeid-duplication bug so name_pending, name_show, name_history, and name_scan actually populate ismine on platforms where wallet::WalletContext typeinfo gets duplicated across the static node and wallet libraries (notably macOS).
• This PR — adds includePending to name_list.
• name_list: mark pending UTXOs with "pending" / "op" fields electrum-nmc#405 — uses the same pending / op field names in electrum-nmc's name_list daemon command output. The field names here are picked to match so wallet UIs written against either backend can share parsing.

This branch is currently stacked on top of #585. The two name-list-side changes (the underlying ismine fix and includePending) are independent, but stacking lets reviewers see the full picture and lets me share the same test infrastructure between the two PRs. If reviewers prefer this PR rebased onto master independently, I'll do it.

Tests

A new functional test, test/functional/name_list_pending.py, covers:

• the default name_list behavior is unchanged,
• includePending without any pending wallet tx matches the default,
• a pending name_update replaces the confirmed entry for that name and carries pending=true, op="name_update",
• confirmed entries for other names are not touched,
• the name filter composes with includePending,
• once the pending tx confirms, the entry loses the pending / op fields and gains real expiration data again.

I ran the full name_*.py battery locally on macOS arm64 with all three commits applied — all 28 tests pass:

TEST                            | STATUS    | DURATION
name_allowexpired.py            | ✓ Passed  |  2 s
name_ant_workflow.py            | ✓ Passed  |  4 s
name_bumpfee.py                 | ✓ Passed  |  2 s
name_byhash.py                  | ✓ Passed  |  1 s
name_encodings.py               | ✓ Passed  | 15 s
name_expiration.py              | ✓ Passed  |  1 s
name_immature_inputs.py         | ✓ Passed  |  8 s
name_ismine.py                  | ✓ Passed  |  3 s
name_list.py                    | ✓ Passed  |  4 s
name_list_pending.py            | ✓ Passed  |  0 s
name_listunspent.py             | ✓ Passed  |  8 s
name_longsalt.py                | ✓ Passed  |  2 s
name_multisig.py                | ✓ Passed  | 16 s
name_multisig.py --bip16-active | ✓ Passed  | 14 s
name_multiupdate.py             | ✓ Passed  |  0 s
name_novalue.py                 | ✓ Passed  |  0 s
name_pending.py                 | ✓ Passed  |  4 s
name_pending_mineonly.py        | ✓ Passed  | 14 s
name_psbt.py                    | ✓ Passed  |  2 s
name_rawtx.py                   | ✓ Passed  |  7 s
name_registration.py            | ✓ Passed  | 18 s
name_reorg.py                   | ✓ Passed  |  1 s
name_scanning.py                | ✓ Passed  |  1 s
name_segwit.py                  | ✓ Passed  |  0 s
name_sendcoins.py               | ✓ Passed  |  0 s
name_txnqueue.py                | ✓ Passed  |  1 s
name_utxo.py                    | ✓ Passed  |  1 s
name_wallet.py                  | ✓ Passed  | 10 s

Build: macOS 15 arm64, clang from Xcode toolchain, CMake build with default flags, ENABLE_WALLET=ON.

RFC notes / questions for review

This is shaped as something close to a draft; happy to iterate on:

• Tie-break for multiple pending wallet txs on the same name. I went with highest nOrderPos (most-recently-added to the wallet). An alternative is "first one found in the mempool that's not RBF-replaced." nOrderPos keeps the implementation entirely wallet-side without needing to consult the mempool again, and matches what a UI would intuitively want ("show me my latest intent"), but I can switch if reviewers prefer the mempool-anchored interpretation.
• Pending replaces confirmed. If reviewers prefer to emit both rows (one pending, one confirmed) for clarity, I can make that the default and gate the merge behind a separate flag like mergePending. That said, every wallet UI I've seen wants the merged view, and the schema cost of adding two rows for one name is non-trivial.
• Mempool-only-not-yet-in-wallet. This PR only includes pending name ops that are in pwallet->mapWallet. It does not include "someone else broadcast a tx that transfers a name to my wallet but the tx isn't in my wallet yet." Adding that would require touching the mempool from name_list, which I'd rather do as a separate change if at all.