rpc: expose node generation identity

[Abdullah1738]

Motivation

Clients that depend on a coherent direct-RPC view need to distinguish a stale response from a current response after daemon restart, and need to detect reorg-away/reorg-back ABA even when height and best block hash return to their prior values.

Change

Add a read-only getnodegeneration RPC returning one atomic snapshot:

{
  "startup_id": "<64 lowercase hexadecimal characters>",
  "chainstate_revision": 1,
  "blocks": 0,
  "bestblockhash": "<64 lowercase hexadecimal characters>"
}

• startup_id is a fresh process-local 256-bit value initialized from the node RNG
• chainstate_revision advances under cs_main when the active chainstate tip or active chainstate identity changes
• revision, height, and best-block hash are captured under the same lock
• revision overflow is fail-stop rather than wrapping
• background snapshot validation does not advance the active revision

The RPC is observational only: it does not change consensus, persistence, P2P, wallet behavior, or startup arguments.

Local verification

• complete test_elements unit suite passed (607 cases)
• complete rpc_tests suite passed (15 cases)
• complete validation_chainstatemanager_tests suite passed (8 cases)
• rpc_getnodegeneration.py passed with RPC documentation checks
• rpc_blockchain.py --v1transport passed
• feature_assumeutxo.py passed
• touched-file, include, include-guard, test-list, diff, whitespace, and Python syntax checks passed

The functional coverage includes clean and forced restarts over the same data directory, exact connect/disconnect increments, reorg-away/reorg-back ABA, concurrent sampling, and rejection of arguments.

[tomt1664]

CI fails on the rpc fuzz target: new commands must be added to one of the allowlists in src/test/fuzz/rpc.cpp. Please add getnodegeneration to the ELEMENTS section of RPC_COMMANDS_SAFE_FOR_FUZZING.

[tomt1664]

What is the immediate use case? Ideally, this could be added upstream to bitcoin first (but that of course would take longer to feed through if required sooner).

If I understand correctly startup_id is the only thing not available currently (by using -zmqpubsequence and waitfornewblock).

[delta1]

Generally looks fine. I initially would have preferred it to be added to getblockchaininfo, but that's a much heavier RPC and this is a cheap atomic snapshot meant to be sampled very frequently.

Some small things:

• as Tom said, please fix CI by adding this to fuzz targets
• in the new RPC description add a brief line about recommended caller behavior (e.g., treat mismatch of startup_id as process restart; use chainstate_revision differences for ABA detection)
• add a changelog entry describing this new RPC
• Overflow handling: AdvanceChainstateRevision asserts if revision == max (fail-stop). Consider adding a short code comment explaining rationale (fail-stop vs wrap) for future readers

[Abdullah1738]

@tomt1664 Immediate value for us is production hardening for a privacy protocol; I’ll also look to send this upstream to Bitcoin Core.