fix(ops): fleet-status collector reports mini-era values on the erlich hub #1657

Important

Problem — The five-minute fleet-status cadence (#1561) runs the mini-era collection script unmodified on the erlich hub, so four probes report false values. The device named "mini" is labeled "this machine" while the collector runs on erlich (the entry list hardcodes its first alias as local). The server guard reports the server not running with an empty pid while the hub serves healthy sessions through the frontdoor → service → engine chain (it probes launchd, which does not exist on the Linux hub). Chat-DB stats are null because the script reads the pre-consolidation opencode-dev.db name — which no longer exists on the hub — and shells out to a sqlite3 CLI that is not installed there (python3's sqlite3 module is the available reader). Vault-sync freshness is null because the BSD date flags fail on Linux and the probe reads a log location the hub does not populate the same way. The dashboard surface built on this file shows a wrong, worrying fleet.
Approach — Rewrite the probes hub-native: identify this machine from the fleet config's canonical ssh alias instead of list position; probe server health via the canonical port plus the engine process's pinned DB environment (no launchd); read the canonical chat DB via python3's sqlite3 module against the pinned canonical DB name; compute vault-sync freshness with portable date parsing against the hub's actual sync log — or report an explicit not-applicable state when the hub runs no client-style sync loop, never a null-by-crash.
Scope — in: the collection script's probes and the cadence unit's environment. out: the projection verb (amico fleet status), the shard-watch census (#1558/#1559), the cadence scheduling itself (working, #1561).