build: make dev venv honor --system-site-packages

Enforces the CLAUDE.md:71 contract ("The venv (and pipx) must use
--system-site-packages") for the dev venv. Previously `uv sync`
auto-created .venv without the flag and then built pycairo/pygobject
from source, so `make install-service` failed on any box lacking
cairo-devel / gobject-introspection-devel / glib2-devel / python3-devel.

Two-part fix in Makefile:

- Pre-create .venv with `uv venv --system-site-packages
--python /usr/bin/python3`. The interpreter pin is load-bearing:
uv's default fetches its own managed CPython, which defeats
--system-site-packages because the distro's gi/cairo live in the
system python's site-packages (e.g. /usr/lib64/python3.14 on
Fedora 43).
- Pass `--no-install-package pygobject --no-install-package pycairo`
to `uv sync` so the lock entries stay but they are not built into
the venv; the system packages are used instead.

`make clean` now also removes .venv. Existing dev boxes rebuild with
`make clean && make install`.

Design notes:

- Existence guard (`[ -f .venv/pyvenv.cfg ] ||`) instead of --clear,
keeping .installed idempotent. Wrong-state venvs require
`make clean` once; auto-detection wasn't worth the complexity.
- uv.lock left untouched: pycairo/pygobject stay resolved but are
skipped at install time (review doc L2 decision).
- pyproject.toml keeps PyGObject in [project.dependencies]
unchanged; pipx (which runs system python3 via
--system-site-packages) still needs the metadata declared.

Out-of-scope follow-up:
tests/test_sync.py::TestQuarantineZeroByte::test_zero_byte_segment_quarantined
fails on main today and continues to fail after this change. It
hardcodes date 20260410 and relies on default 7-day retention; on
2026-04-22 the .failed directory is swept by the cleanup pass in
the same _sync() call before the assertion runs. Reproducible on
both the old (CPython 3.13) and new (CPython 3.14) venv — not
caused by this lode.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>