test(peer): prove bring-up installs the downstream engines on the real genesis (#240)

[MichaelTaylor3d]

Task

dig-node#240 item 1 — the finite checklist's remaining substance: prove pool/DHT/PEX actually come
up against the real DIG L2 genesis, not merely that the genesis constant is correct.

What this PR does

Adds crates/dig-node-core/tests/genesis_bringup.rs, a hermetic end-to-end test asserting the
DOWNSTREAM post-conditions of a successful run_peer_network bring-up against the real default
genesis (no DIG_NETWORK_GENESIS override):

• Node::gossip_handle() is Some — the gossip pool started.
• Node::p2p_content() is Some — the P2P content engine is installed (wired only once the DHT is up).
• Node::has_inventory_refresher() (new observable, added to the PeerNetwork trait) — the DHT
  inventory-refresh hook is installed.
• the mTLS peer-RPC listener accepts a loopback TCP connection.

running == true is deliberately NOT asserted — it is set before the pool exists and holds even
when every downstream step fails, which is exactly why #240 needed a new test rather than a
strengthened one (the same failure serve_with_gate_on_starts_the_peer_network_and_still_serves_reads
had).

Scope, stated plainly (also in the test's own module doc): this proves the bring-up completes
against the real genesis in a single hermetic process (relay off, loopback only). It does NOT prove
PEX behaviour, multi-peer convergence, or the relay reservation/accept loop — those need more than
one host and are the multi-node e2e's job (#1062), not this test's.

Also updates one stale lib.rs doc-comment (#213's chain-watch test) that described the old
"placeholder genesis rejects the gossip config" world; it now cites this test and states the real
reason the pool doesn't converge in that test's env (no peer to reach, not a rejected config).

Item 2 — NOT included here, already covered elsewhere

#240's other checklist item (4 stale SPEC.md clauses describing the old placeholder-genesis
behaviour) is already addressed on open PR #530 (loop/242-241-396-240), with more complete citations
than a duplicate fix here would have (it cites genesis_challenge_env_override's unit tests and
correctly flags item 1 as open pending this test). I read that diff before touching SPEC.md and
reverted my own parallel edit to avoid two lanes rewriting the same lines. #530's SPEC.md text
currently says "no test in this crate yet exercises the full bring-up ... tracked as #240 item 1" —
once this PR merges that sentence should be updated to point at tests/genesis_bringup.rs as a
one-line follow-up (flagging for whoever sequences the two merges).

This PR alone leaves dig-node issue 240 open — item 2 lives on #530. Recommend a manual resolution of dig-node issue 240
once both PRs are merged, or adding a closing keyword to whichever of the two lands second.

How verified

• cargo test -p dig-node-core --test genesis_bringup: 1 passed; 0 failed; 0 filtered out.
• Non-vacuity control: temporarily forced has_inventory_refresher() to return false — test
  correctly FAILED (refresher=false, panic at the assertion), confirming it actually exercises
  the claimed post-condition rather than passing vacuously. Reverted before commit.
• cargo check -p dig-node-core --all-targets: clean.

Version

0.253.5 (Cargo.toml + Cargo.lock). Merged origin/main (not rebased) into this branch first;
0.253.0/0.253.1/0.253.2 are already claimed by concurrently open PRs #524/#528/#518, and 0.252.98/99
by #402/#530.

Contributes to (does not resolve on its own): #240