Adds GET /diagnostics, a single JSON endpoint that summarizes the running
CADT, Chia, DataLayer, and host machine state. The endpoint is intended for
sysadmins debugging a CADT install: it reports CADT version, configured /
actual chia network, wallet/full-node/datalayer reachability + sync status,
wallet balance, trusted-peer cross-reference, DataLayer subscriptions with
per-store sync status, governance body IDs, V1/V2 home org IDs, datalayer
URLs, CADT config + database paths, CPU/RAM/disk numbers, a chia process
scan, and a chia-tools probe.

The endpoint is mounted on the root app (not /v1 or /v2) and lives in
HEALTH_ENDPOINTS so it bypasses the rate limiter, startup gates, and the
chia/datalayer assertions -- the whole point of a diagnostics endpoint is
to be useful when those subsystems are broken. Every external call goes
through a settle() wrapper with a per-call timeout and Promise.all fan-out,
so one slow or wedged RPC can't block the rest of the response. Worst-case
wall-clock is ~30s (subscription enumeration budget); healthy responses
come back in well under a second.

Authentication is enforced by the existing global API-key middleware (no
duplicate check needed). When V1 or V2 READ_ONLY is set, the response is
reduced to non-sensitive public data and short-circuits before the wallet
/ datalayer RPC fan-out, matching the precedent in wallet-health.js.

Also adds isHealthEndpoint() skips to the wallet-synced, home-org-synced,
and all-data-synced header middlewares so /diagnostics (and /health*)
don't hang on the wallet RPC's 300s socket timeout or on waitForMigrations
when the database layer is the broken subsystem.

…en network match

Two fixes from bugbot review of #1627:

1. Move dynamic imports of wallet / fullNodeRpc / persistance / V1+V2
   models / fullNode AFTER the read-only short-circuit. The PR description
   said the read-only path short-circuits before fetch, but the heavy
   imports were happening unconditionally, which (a) made public observer
   nodes load DB and wallet modules they don't need and (b) caused
   /diagnostics to fail in the exact scenarios it's designed to survive
   (e.g. V2 model module body failing to initialize).

2. Use exact equality (not substring containment) for the network match.
   `"testnet10".includes("testnet1")` is true, so the previous code
   reported a false match when the configured network was a prefix of
   the actual one. The diagnostics endpoint's job is to tell the truth;
   the existing assertChiaNetworkMatchInConfiguration still uses the
   substring rule, but the `actual` and `configured` fields in the
   response let operators spot whether the loose-match assertion would
   also have considered them equivalent.

Defensive fix from bugbot review of #1627. Node's fs.statfs() currently
only exposes bsize (libuv's uv_statfs_t doesn't copy frsize from the
underlying statfs(2) syscall), and on Linux+ext4 'blocks * bsize'
matches 'df -B1' byte-exactly. But POSIX statvfs denominates blocks in
frsize, not bsize, and on exotic filesystems (e.g. VirtioFS on Docker)
the two can differ. Using 'stats.frsize ?? stats.bsize' is a zero-cost
hedge that automatically picks up frsize if a future Node version or a
polyfill exposes it, while keeping today's behavior unchanged on every
mainstream environment.

…tics

CADT's CHIA_NETWORK config is a binary mainnet-vs-testnet flag, not an
exact chia network name. Cross-referenced against every use in the
codebase:

  - defaultConfig.js sets it to 'mainnet'
  - config-loader.js forces it to the literal string 'testnet' when
    USE_SIMULATOR=true, regardless of the actual underlying network
  - coin-management.js branches on '=== mainnet ? XCH : TXCH'
  - data-assertions.js accepts any chia network whose name contains
    CHIA_NETWORK as a substring

The CI run on commit 286fcbb confirmed the previous strict-equality
check gave the wrong answer in the real world: chia reported 'testneta',
CADT config was 'testnet', diagnostics reported matches:false even
though CADT itself treats them as a match.

Normalize both sides to mainnet|testnet before comparing. This is both
strictly more correct than the original substring rule (no
testnet1/testnet10 false positive) and operationally aligned with how
the rest of CADT interprets CHIA_NETWORK.

The existing assertChiaNetworkMatchInConfiguration still uses the
substring rule -- harmonising the assertion with this normalised
comparison is a sensible follow-up but is left out of this PR to keep
the scope tight.

The syncMode ternary used a truthy check for state.sync?.synced while
the synced field on the same line used === true. A non-boolean truthy
value (e.g. 1) would produce synced: false alongside syncMode: 'synced'.

- Promote network match to top-level "network" key with "chia"/"cadt"
  sub-keys instead of "chia.network.actual"/"configured"
- Rename "processes" to "runningProcesses", drop redundant "supported"
  and "platform" fields (already in system section)
- Add "percentUsed" to both memory and disk sections
- Rename disk "path" to "chiaRootPath" for clarity
- Add "runningLocally" to fullNode section; skip full-node RPC calls
  when process scan confirms no local chia_full_node (falls back to
  optimistic probe when scan is unsupported or fails)

Query the wallet RPC get_version endpoint and surface the installed
Chia version in chia.version (null when the wallet is unreachable).

getWalletConnections catches errors internally and returns
{ success: false, error } instead of throwing, so settle() always
sees ok: true. Check value.success before treating connections as
valid, and surface the inner error when the wallet call failed.

…eRpc

Restore try-catch in getChiaVersion so it is safe for callers outside
of settle(). Add explicit NODE_TLS_REJECT_UNAUTHORIZED to fullNodeRpc.js
so it does not rely on wallet.js import order as a side effect.

getWalletHealthResponse already calls walletIsSynced internally, so
the parallel direct call doubled RPC load and raced on the module-level
lastWalletSyncError variable (each call clears it to null). Derive
synced from the wallet health response instead.

getDiagnosticsResponse handles all subsystem failures internally via
settle(), so an exception reaching the outer catch is a genuine bug
that should be surfaced to monitoring tools as a 500.