Local TEST probe observer

The operator-controlled TEST onion probe has previously stalled while its RPC continued answering. compose.pilot-observer.yaml runs a separate read-only observer on the two existing TEST Docker networks. It checks chain ID, genesis, fresh block timestamps, a maximum two-block head difference and a matching common block. The probe and reference remain controlled by the same operator; this is not evidence of an independent validator or a complete transport audit.

Start the existing TEST services first, then run from this project directory:

docker compose -f compose.pilot-observer.yaml up -d
docker compose -f compose.pilot-observer.yaml ps
docker compose -f compose.pilot-observer.yaml logs --tail=10

The observer samples approximately once a minute. Docker health is healthy only after a successful recent sample. A stale block, divergent history, excessive lag, wrong network, unavailable RPC or expired/missing status file is unhealthy. Status and common block information are in bounded Docker logs; health is a local signal, not an automatic notification or proof of uninterrupted history.

The service has no signing keys, Docker socket, exposed port or writable project mount. It joins both TEST networks and can reach their RPC interfaces; protect those networks accordingly. It drops capabilities and uses a read-only root filesystem and bounded memory. It never restarts a node. The usual Docker restart policy only restarts the observer process after it exits; an unhealthy status alone does not repair either node. Check the reference's freshness and resource headroom before a separately watched recovery. A long catch-up can load the reference validator even when the probe is the only container restarted.

An existing probe's container health or this observer's latest success does not prove the entire past 72-hour window or detect all JVM memory trends. This is monitoring, not the previously proposed automatic supervisor.