feat: --healthcheck for monitoring and systemd watchdogs

[mehowz]

Summary

Adds a `Healthcheck` menu option + `--healthcheck` CLI flag that
runs diagnostic checks against the local node and exits with a
status code suitable for monitoring tools. Fills the gap between
`Status` (human-readable, interactive-only) and nothing.

Stacks on #11 and #12 — please review / merge those first. The
diff this PR adds over #12 is 134 insertions across one commit
(`fe9d699`).

Output format

Healthcheck
-----------
[PASS] service        go-zenon.service is active
[PASS] binary         znnd version v0.0.8-abcdef
[PASS] rpc            reachable at ws://127.0.0.1:35998
[PASS] sync           height=12345678 lag=3s (threshold: 15s healthy, 60s warn)
[PASS] pillar         mypillar1 (z1qxemdeddedxt0ken...), produced=42 this epoch
-----------
HEALTHY

Thresholds: sync lag ≤15s is `[PASS]`, ≤60s is `[WARN]` (warns but
doesn't fail), >60s is `[FAIL]`. These match the 10s target block time
with headroom for short-term jitter. Exit `0` if no `FAIL`, `1`
otherwise. `WARN` conditions don't fail the overall check — the
operator reads the output and decides.

Checks

1. Service — `systemctl is-active go-zenon.service`. `FAIL` if
   inactive.
2. Binary — `/usr/local/bin/znnd` exists and `znnd version`
   returns. `FAIL` if missing.
3. RPC — `ws://127.0.0.1:$defaultWsPort` connects within 10s
   timeout. `FAIL` if unreachable. Skipped if service is inactive
   (would double-report).
4. Sync — `getFrontierMomentum()` with 10s timeout, compute
   wall-clock lag vs `momentum.timestamp`. `FAIL` if timeout,
   `PASS`/`WARN`/`FAIL` by lag threshold.
5. Pillar — only runs if producer config exists. Enumerates
   `embedded.pillar.getAll` until the producer address is found or
   pagination exhausts. `PASS` if registered and produced >0 this
   epoch; `WARN` if registered but produced=0; absent from `PASS`
   registry → `WARN`.

All RPC calls carry explicit timeouts so a stuck node doesn't cause
the healthcheck itself to hang — which is exactly the failure mode
the check is meant to detect.

Use cases

Designed to drop into existing monitoring plumbing:

• systemd watchdog — `WatchdogSec=60` plus a timer unit running
  `znn-controller --healthcheck`
• cron + mail-on-nonzero — for passive monitoring
• Nagios / Icinga — `check_exit` wrapper consumes the exit code
• Ansible / Terraform — post-deploy verification
• Container liveness probe — in a containerised pillar deployment

Test plan

Docker (Ubuntu 24.04, no running znnd):

• `--healthcheck` exits 1, prints `UNHEALTHY` with
  `[FAIL] service` + `[FAIL] binary`
• Menu item `Healthcheck` selectable in interactive mode
• Output works with ANSI stripped (test script verified clean
  grep-ability)

A running-znnd integration test would need a real node spun up; not
in scope for the PR itself but straightforward to add to follow-up CI.

Scope

• No changes to existing flows (`Status`, `Deploy`, services) — this
  PR is strictly additive.
• Uses `znn_sdk_dart` types already imported for `Status`
  (`Zenon`, `PillarInfo`, `PillarInfoList`, `Momentum`). No new
  dependency.