Fix /roster harness discovery — spawn selector shows "no harnesses available"

Operator reports /roster spawn shows "no harnesses available" and can't spawn a daemon. NOT the injection/timers gap — spawn uses `solo-cli processes spawn`, which exists. This is a harness-DISCOVERY bug. Evidence (2026-07-02): `solo-cli agents list` (raw CLI) returns 8+ tools (Gemini=1, OpenCode=2, Claude=3, Codex=4, Amp=5, Copilot=8, Kimi=9, Pi=10). But `SoloClient::agentTools()` returns only 1 from php CLI/tinker context, and /roster (SoloAgentToolService → `SoloClient::agents()` shelling `agents list`, per app/Services/Solo/SoloAgentToolService.php:56/66 blocker messages) shows 0 in the web context. Two layers to chase: (a) parse/filter discrepancy — why the app returns 1 (or the wrong shape) vs the CLI's 8; (b) web-context failure — the Livewire/Herd php-fpm request shells solo-cli in an env that likely lacks the HOME/discovery access an interactive shell has (discovery at ~/.config/soloterm/http-api.json IS readable but has a Jun-25 mtime; solo.binary is absolute so PATH isn't it; SOLO_APP_DATA_DIR correctly unset). Needs LIVE diagnosis in the actual web/Herd context (NOT sqlite) — this is orchestrator-on-MAIN work, not a worktree sqlite build: reproduce /roster's harness fetch under Herd, capture the SoloCliException/empty result, diff env (HOME, discovery resolution) between CLI and php-fpm. BLOCKS the #62 spawn feature end-to-end AND 66c/#72 (Water the garden needs working web-context spawn). Deliverable: harnesses list + spawn work from /roster in the browser.