fix(fleet): shard-watch client census uses the canonical literal DB path — broken on mixed-OS fleets

[aarontrowbridge]

Problem

The #1306 shard-watch's client census runs over ssh as:

sqlite3 -readonly <dbPath> 'SELECT id FROM session'

where dbPath is the canonical DB path resolved on the hub (linux: /home/aaron/.local/share/opencode/opencode.db). The path is embedded literally into the remote command, so on any client whose home differs — every macOS client (/Users/aaron/...) — the remote sqlite3 fails and ssh relays exit 1. The client is then recorded as unreachable, which the design treats as a warning — so the watch silently never actually censuses any macOS client. On the live fleet this means the macbook (the one machine with a real fork history, #1302, DB actively diverging today) is unreachable-by-construction every night.

Deployed evidence (erlich, 2026-09-25): AMICO_SHARD_CLIENTS=macbook → receipt {verdict: "unreachable", error: "ssh exited 1"} while the same ssh alias + interactive ssh macbook 'ls ~/.local/share/opencode/opencode.db' succeeds (the DB exists, 873 MB, actively written).

Approach

The client census command should address the remote DB home-relatively — ~/.local/share/opencode/opencode.db (or $HOME/...) — which resolves on both linux and macOS clients. The canonical-path flag/env stays untouched for the canonical read (that one is local to the hub and correct). Options (pick the cleanest):

1. clientCensusCommand derives a ~-relative path when the canonical dbPath lives under the hub home (the overwhelmingly common fleet layout: same XDG-relative location, different $HOME), OR
2. an explicit --client-db <path> flag / AMICO_SHARD_CLIENT_DB env with the ~-relative default (1) — keeps exotic layouts expressible.

Also: pin the fork-listener command's port-only assumptions (it's already client-remote and path-free — fine).

Acceptance criteria

• clientCensusCommand (or its replacement) emits a home-relative remote path by default; the remote command succeeds on a macOS-layout client when the hub is linux (table-test the string, follow the existing shard_watch.test.ts command-builder patterns).
• A client whose $HOME differs from the hub's is censused, not unreachable (hermetic test via the probe seam).
• The canonical census path (--db, OPENCODE_DB) semantics unchanged; existing shard-watch tests stay green or are extended, never weakened.
• Live check on the real fleet after merge: receipt shows macbook verdict: clean|divergent with real counts, not unreachable.

Prior art / evidence

• Deployment receipts: ~/.amico/server/upgrade-receipts/upgrade-receipts.jsonl (kind shard-watch, ts 2026-09-25T12:1x — unreachable for both macbook and mini).
• macbook DB confirmed live at /Users/aaron/.local/share/opencode/opencode.db (fork-history machine, amicode#1302).
• The mini is a thin client since 2026-09-20 (no local DB) — its row is expected to stay unreachable-as-warning or be dropped from AMICO_SHARD_CLIENTS; the macbook is the load-bearing watch target.

Discovered during the #1301 deployment pass (session ledger session-20260925-system-engine-phase0).