fix(updater): declare packaging as a runtime dependency, fix rc-vs-GA fallback

[thinmintdev]

Closes #1640

Summary

Release-blocker found in pre-rc.2 review: the updater's version comparison
_is_newer (duplicated in hal0.updater.updater and
hal0.api.routes.updater) prefers packaging.version.Version for PEP 440
comparison but silently falls back to a naive digit-tuple compare when
packaging can't be imported. packaging was declared nowhere in
[project].dependencies — it was only a transitive dep of the dev extra
(pulled in by pytest). A production venv built by the installer (no dev
extras) never has it, so every real box hits the broken fallback.

Repro (independently verified before fixing)

The fallback's digit-tuple parser reads "1.0.0rc1" — the pip-normalised
form importlib.metadata.version("hal0ai") reports for an installed
1.0.0-rc.1 — by stripping the rc letters and keeping the 1, producing
(1, 0, 1). That's identical to _version_tuple("1.0.1") and greater than
_version_tuple("1.0.0"). Result: a 1.0.0rc1 box is told 1.0.0 GA is
"not newer" and 1.0.1 GA is "not newer" (tied) — it would never be offered
either.

>>> _version_tuple("1.0.0")       # candidate GA
(1, 0, 0)
>>> _version_tuple("1.0.0rc1")    # installed
(1, 0, 1)
>>> (1, 0, 0) > (1, 0, 1)         # "is 1.0.0 newer than 1.0.0rc1?"
False   # bug: it is, but the fallback says no

Fix

• pyproject.toml: add packaging>=24 to [project].dependencies
  (already an indirect dep of dev, pinned loosely) and relock uv.lock.
  This is the durable fix — every install going forward ships packaging.
• _naive_version_key (new, in both hal0/updater/updater.py and
  hal0/api/routes/updater.py, mirroring the existing duplication): replaces
  the raw _version_tuple compare in the packaging-absent fallback branch
  of _is_newer. It recognizes the common a/alpha/b/beta/c/rc/pre/preview
  prerelease forms (both pip-normalised 1.0.0rc1 and tag-derived
  1.0.0-rc.1) and ranks a prerelease below its own final release. Anything
  it doesn't recognize (nightly timestamp tags, malformed strings) keeps the
  original digit-tuple behavior, so existing nightly monotonicity is
  unaffected.

Honest caveat — who actually benefits, and who doesn't (updated after review)

The old updater's version check runs in the OLD, already-installed code
before the new release tarball is even downloaded — by the time new code
is running, the decision to offer the update has already been made. Concretely
(hal0 update, src/hal0/cli/update_commands.py:507-520):

1. It calls GET /api/updates/check, served by the OLD, already-running
   daemon — OLD _is_newer, OLD broken fallback.
2. If that reports update_available: false, the CLI prints "nothing to
   apply" and exits at line 518, before any download, before any new code
   ever runs.

So: an already-stuck 1.0.0rc1 box on the OLD fallback cannot self-heal via
the plain hal0 update path, no matter what this PR ships — the corrected
_naive_version_key fallback lives in the new code that box never reaches on
its own. (An earlier draft of this section claimed otherwise; a codex review
comment on this PR caught that it's wrong — see the discussion thread.)

• The packaging>=24 dependency fix protects updates initiated from a venv
  built after this change lands (a fresh install, or a box that has
  already updated once past this PR) — that population is fully fixed.
• A box already stuck on a pre-fix venv needs an operator-initiated
  rescue, which already exists and needed no new code:
  hal0 update --target <version> (e.g. hal0 update --target 1.0.0).
  --target sets target_version, which bypasses the update_available
  gate entirely (update_commands.py:518), and /api/updates/prepare never
  calls _is_newer — it stages whatever version is requested directly. Run
  hal0 update --check first to confirm the real latest version (_print_check
  always shows the true latest from the manifest fetch, independent of the
  broken comparison, even when it's mislabeled "up to date").

Once a box updates via --target, it's running this PR's code and the
packaging dependency + corrected fallback, so every subsequent plain
hal0 update behaves correctly again.

Test plan

• New unit tests in tests/updater/test_updater.py force the
  packaging.version import to fail (monkeypatched builtins.__import__)
  and exercise _is_newer's fallback branch directly:
  - 1.0.0rc1 vs 1.0.0 (both directions)
  - 1.0.0rc1 vs 1.0.1 (both directions)
  - tag-derived 1.0.0-rc.1 form (vs 1.0.0, 1.0.1, and 1.0.0-rc.2)
  - nightly timestamp regression (unaffected by the fallback change)
• HAL0_HOME=$(mktemp -d) uv run --extra dev pytest tests/updater tests/release -x — 335 passed
• tests/api/test_updater_routes.py — 50 passed
• ruff check on all changed files — clean
• uv lock — minimal diff, packaging moves from pytest-only
  transitive dep to a direct hal0ai dependency
• mypy — no new errors introduced (pre-existing errors elsewhere in
  updater.py, unrelated to this change, confirmed present on main too)

🤖 Generated with Claude Code

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 4ff215da17

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Bootstrap installed RC clients before relying on this fallback

When upgrading an already-installed 1.0.0rc1 production venv—the population this fallback is intended to rescue—this branch is unreachable: /api/updates/check executes the old installed module before downloading or reinstalling anything, and the CLI exits at src/hal0/cli/update_commands.py:518 when that old comparison reports no update. Because the old tuple logic rejects 1.0.0-rc.2, 1.0.0, and 1.0.1, shipping this helper and the new dependency only protects fresh or already-bootstrapped installs; provide a bootstrap path that the old client can invoke, such as an explicit targeted update or installer flow.

Useful? React with 👍 / 👎.

[thinmintdev]

Verified — checked src/hal0/cli/update_commands.py:517 and the /api/updates/prepare route (src/hal0/api/routes/updater.py:735). Confirmed correct: this is unreachable for an already-stuck box via the default hal0 update path since the OLD check route (which calls the OLD, broken _is_newer) sets update_available=False and the CLI bails at line 518.

But the rescue path already exists and doesn't need new code: hal0 update --target <version> (line 429) sets target_version, which bypasses the update_available gate entirely (if not body.get("update_available") and not target_version), and /api/updates/prepare never calls _is_newer — it stages whatever version is requested directly. _print_check also always prints the real latest from the manifest fetch (independent of the broken comparison), so an operator running hal0 update --check on a stuck box still sees the true latest version to pass to --target.

Updating the PR body's caveat section to name this explicitly as the operator recovery path for boxes already stuck on a pre-fix venv, so it's documented rather than tribal knowledge. Not adding new code for this — the existing --target flag already covers it.