fix(portable): reinstall anthropic provider on venv rebuild

[jamesphenry]

Summary

The post-reboot venv rebuild path in launch.sh was missing the
anthropic provider install. The venv is created on the local
filesystem (typically /tmp on Linux, $TMPDIR on macOS — see
launch.sh lines 79-80 and 100-108) rather than on the USB, partly
to avoid exFAT hardlink limitations and partly to keep the venv off
the drive for speed and wear. The result is that the venv is wiped on
every reboot, and the rebuild block in launch.sh is responsible for
re-installing everything the first-run scripts/setup-unix.sh
installed. Step 9 of setup-unix.sh installs anthropic; the
rebuild block did not, so chat would fail with an import error when
the agent tried to use the Anthropic provider after any reboot.

Reproduction

1. Run ./launch.sh on a fresh drive. First-run setup completes
   successfully.
2. Configure Hermes with the Anthropic provider via the launcher
   menu. Verify chat works.
3. Reboot the laptop. The local venv on /tmp (or $TMPDIR on
   macOS) is cleared, the venv goes with it.
4. Run ./launch.sh again. The "Local venv not found (temp was
   likely cleared). Rebuilding ..." banner appears.
5. Try to chat. The agent fails to load with an import error
   referencing the anthropic module.

Root cause

launch.sh lines 92-128 (rebuild path) install the core
hermes-agent[all] package and python-telegram-bot, but not
anthropic. scripts/setup-unix.sh line 381 installs anthropic
during first-run setup. The two paths are supposed to be equivalent
on the install side (the hermes-agent[all] extra is deliberately
not exhaustive — see the comment in setup-unix.sh step 10), but the
rebuild path drifted.

Fix

Add anthropic>=0.39.0 to both the uv install line and the pip
fallback line in the rebuild block, matching the version specifier
from setup-unix.sh step 9. Add a comment above the block explaining
the sync requirement so the next person who edits either file knows
to update both.

+    # NOTE: This install list must stay in sync with scripts/setup-unix.sh
+    # (steps 8, 9, 10). setup-unix.sh installs core + anthropic + telegram
+    # because [all] is deliberately not exhaustive. The rebuild path here
+    # replicates the same three packages; drift between the two paths is
+    # the root cause of "library not installed" errors after reboot.
     if ! "$UV_EXE" pip install --python "$VIRTUAL_ENV/bin/python" --link-mode=copy \
         -e "$SRC_DIR/hermes-agent[all]" \
+        "anthropic>=0.39.0" \
         "python-telegram-bot[webhooks]==22.6" 2>/dev/null; then
         "$VIRTUAL_ENV/bin/python" -m ensurepip --upgrade >/dev/null 2>&1 || true
         "$VIRTUAL_ENV/bin/python" -m pip install \
             -e "$SRC_DIR/hermes-agent[all]" \
+            "anthropic>=0.39.0" \
             "python-telegram-bot[webhooks]==22.6" 2>/dev/null || true
     fi

How to verify

1. Reboot the laptop (or rm -rf the path in
   .cache/runtimes/<platform>-<arch>/venv.path).
2. Run ./launch.sh. The rebuild banner appears and the install
   log should include anthropic next to the other two packages.
3. From the chat, send any message routed to the Anthropic provider.
   It should return a model response, not an import error.

Test plan

• Rebuilt venv on a Chromebook running Debian 13 (Trixie) +
  XFCE. The rebuild block ran, anthropic was installed alongside
  the other two packages, and chat resumed normally.
• bash -n launch.sh passes (syntax valid).
• Diff against main is 7 lines added, 0 removed, in one file.

Risk assessment

Low. The change is additive — it adds a package to an existing
install list, doesn't change the venv creation logic, doesn't touch
the uv venv invocation, and doesn't change the install order. The
only behavioural change is "anthropic gets reinstalled on rebuild
like it does on first-run setup," which is the intended behaviour
matching the first-run path. If the uv install fails for any
reason, the existing pip fallback catches it with the same package
list.

A longer-term refactor would extract the install list into a
shared function so the two paths can't drift again, but that's a
bigger change and out of scope for this fix.

Notes

• This is my first contribution to this project — happy to make
  changes if anything in the diff or commit message doesn't match
  the project's conventions.
• I couldn't find an existing issue or PR for this, but let me know
  if I've missed one and I'm happy to coordinate.

[jamesphenry]

Heads up: PR #7
(open) moves the venv to ~/.cache/hermes-portable/<id>/ (local disk)
so the rebuild block runs far less often — which would make this PR's
rebuild-block install redundant if #7 lands first.

If that's the case, no problem — happy to close this PR or rebase it
onto #7 (preserving the "two install paths must stay in sync" comment
as a guard for future drift). Whichever you prefer.

If #7 isn't landing soon, this PR still fixes the reported bug as-is.