Stop making the repo clone load-bearing for the running service

[STRML]

plists.py:54 bakes @WORKDIR@ = REPO_ROOT into the rendered plist, and the job runs uv run uvicorn ... from there. Two consequences, neither documented:

• Moving or deleting the clone breaks the service. launchd keeps restarting it (KeepAlive is true), the failure only shows up as a nonzero exit in /tmp/hark.err, and nothing points at the real cause.
• git pull live-patches a running daemon. The next request runs whatever just landed, without a reload you asked for.

test_workdir_is_the_repo_root currently asserts this coupling holds, so it is deliberate rather than accidental. The suggestion is to change the intent, not to call it a bug.

Fix: install the package somewhere stable (uv tool install ., or a venv under ~/.local/share/hark) and point ProgramArguments at that instead of at the clone. The clone becomes disposable, and upgrades become an explicit reinstall.

Worth checking against #4 first, since that one changes what the server needs at runtime.

[drycode]

Fixed in 8d12f7b.

install-server.sh now installs the package into ~/.local/share/hark/venv,
and the plist names that uvicorn by absolute path with no
WorkingDirectory at all — nothing in the job resolves a relative path, so
the key was only ever tying the daemon to the checkout. uv is now needed to
install the service, not to run it.

You were right that the coupling was deliberate rather than accidental, so
test_workdir_is_the_repo_root is replaced rather than repaired — the intent
changed. Three tests take its place: the program is the installed venv, nothing
in ProgramArguments points into the clone, and WorkingDirectory is absent.
--doctor also gains an install check, including the case where uvicorn is on
disk but the venv cannot import hark — an existence check alone would PASS
there while launchd cannot start the app at all.

The venv is rebuilt from scratch on every install, so a dependency dropped from
pyproject.toml actually leaves instead of lingering in an environment nobody
rebuilds.

Verified

With the clone moved out of the way entirely:

$ mv hark hark.moved
$ curl -o /dev/null -w '%{http_code}' .../health
200
$ curl -X POST .../dictate -H "X-Hark-Key: ..." -H 'Content-Type: audio/wav' \
       --data-binary @probe.wav
{"text":""}   [HTTP 200]

A full round trip — auth, energy gate, response — with no checkout on disk.
({"text":""} is correct: that WAV is silence, so the gate returns empty.)

Two things this turned up

Rendering has to stay in the clone. The templates live in launchd/ and are
not shipped in the wheel, so python -m hark.plists from the installed copy
raised FileNotFoundError on a path inside site-packages/. That is how it was
found — the first real install failed on it. It now prints what to do instead,
with a test.

A re-run could leave the service down (36c6a79, separate commit). launchctl bootout returns before launchd finishes tearing the job down, and bootstrapping
into that window fails with Input/output error: 5; under set -e that aborted
the install with the service booted out and never brought back. A re-run whose
whole promise is that it is safe was taking dictation down and saying only
"Bootstrap failed". Now it waits for the label to leave the listing, retries, and
fails loudly rather than continuing to the health check with nothing running.

Both of those were only findable by running the thing, which is a fair argument
for your framing on this issue: the clone being load-bearing hid how little of
the install path was actually exercised.