fix(service): anchor identity + cache under the state dir, not $HOME

[MichaelTaylor3d]

Fixes DIG-Network/dig_ecosystem#1928.

What was wrong

A stock .deb install never joins the P2P network. Found on three fresh installs while standing up the 3-region node fleet (DIG-Network/dig_ecosystem#1927) — nothing customised, just apt install ./dig-node_0.71.0_arm64.deb:

dig-node: no identity key (Read-only file system (os error 30)); authenticated §21 sync disabled
dig-node: peer network bring-up failed: no identity seed; peer network needs a stable identity

Two individually-reasonable halves that are jointly fatal:

1. packaging/linux/systemd/net.dignetwork.dig-node.service sets ProtectHome=true; systemd runs the root service with HOME=/root, so /root is unreadable.
2. The identity seed path is dirs::config_dir()/dig/identity_key.bin → $HOME/.config/dig — inside the directory the sandbox just blanked.

So load_or_create_seed() fails EROFS, Node::from_env() sets identity_seed: None, and peer.rs refuses bring-up. The cache collides identically, falling back to /tmp/DigNode-<pid>/cache, which does not survive a restart — so even a node that did start could never accumulate anything to reshare.

Confirmed by differential, same binary, same box:

$ systemd-run --pipe --wait --property=ProtectHome=true -E HOME=/root /usr/bin/dig-node --json peers
WARN canonical cache dir /root/DigNode/cache is not writable; falling back to /tmp/DigNode-1876/cache
{"running":false,...,"last_error":"no identity seed; peer network needs a stable identity"}

The fix

Anchored as a property of a SERVICE RUN, not of the Linux packaging — the macOS launchd daemon and the Windows service inherit the same home-relative default, so fixing only the unit would leave two of three platforms carrying the bug. On a service run the identity and cache resolve under the machine state dir the service already resolves and hardens (#501), before the identity is first loaded.

• A CLI run is untouched: the user's identity stays shared with their other DIG tools.
• An operator-set DIG_IDENTITY_DIR / DIG_NODE_CACHE is never overridden.
• The env write happens at the top of the entrypoint, before the runtime or any thread exists.

How verified

Live, on the #1927 fleet — same package, only the equivalent drop-in added:

dig-node peer network: peer_id 53008105ca451509c851e984a11ed05e84cd57cb3cbb5374d068d3a8336d6c46
dig-node peer network: connected peer pool up (discovery via wss://relay.dig.net:443)
INFO dig_nat::relay: relay reservation established connected_peers=2
dig-node peer network: mTLS peer-RPC listening on [::]:9444 (dual-stack, IPv6-first)

All three regions went from running:false to running:true with a held relay reservation.

Suite: 294 dig-node-service lib tests green, fmt + clippy --all-targets -D warnings clean. The four new tests assert the decision rather than a #[cfg(unix)] filesystem effect, so the guard stays falsifiable on every host CI runs on instead of being silently unexercised on Windows.

SPEC.md §7.3a gains the normative rule.

Minor bump: 0.71.1 → 0.72.0.

Co-Authored-By: Claude noreply@anthropic.com