Feature request: llmfit self-update mechanism

## Feature request: `llmfit` self-update mechanism

### Problem

`llmfit` currently has no way to check for or apply new releases of the tool itself. `llmfit update` only refreshes the local model database from HuggingFace — it does not touch the `llmfit` binary. Users must notice a new release manually (via GitHub, the README badge, etc.) and re-run their original install method to upgrade.

Given how many install paths this project supports (Homebrew tap, homebrew-core, MacPorts, `install.sh` prebuilt binary, `uv tool` / `pip`, Docker/Podman, `cargo install` / crates.io, build-from-source), users on the same "latest" install rarely know they're behind, and there's no consistent UX across install methods for closing that gap.

### Proposal

1. **Version check**: on a cadence (e.g. once per day, cached — not on every invocation) or via an explicit command, check the latest published version against the running binary's version.
- Compare semver, ignoring release-please's `v` tag prefix.
- Read the latest version from the GitHub Releases API (or an existing lightweight endpoint, mirroring how the project already publishes `CHANGELOG.md`/tags via release-please).
2. **Notify, don't surprise**: when behind, print a one-line notice (TUI: a dismissible banner/footer hint; CLI: a stderr line that doesn't interfere with `--json` output) — never block or auto-mutate without consent.
3. **Install-method-aware upgrade**:
- Detect how the running binary was installed (e.g. a stamped marker at build time, or heuristics on the binary's path — brew Cellar/Caskroom path, `cargo`'s `~/.cargo/bin`, `uv tool` dir, Docker/container, etc.).
- For methods llmfit can safely self-manage (e.g. the `install.sh` prebuilt-binary path), offer an explicit `llmfit self-update` (or similar) that downloads and swaps the binary — never automatic/unattended by default.
- For methods managed by an external package manager (Homebrew, MacPorts, `uv tool`, Docker, cargo), print the exact command the user should run instead (`brew upgrade llmfit`, `port upgrade llmfit`, `uv tool upgrade llmfit`, `docker pull ...`, `cargo install llmfit --force`) rather than trying to self-modify a file it doesn't own.
4. **Respect opt-out**: an env var (e.g. `LLMFIT_NO_UPDATE_CHECK=1`) and/or a config flag to disable the check entirely — useful for CI, Docker, and offline/air-gapped use.
5. **`llmfit doctor` integration**: include current vs. latest version in the existing `llmfit doctor` diagnostic report.

### Non-goals

- No change to `llmfit update`'s existing behavior (model DB refresh) — this is a separate concern from binary self-update; naming should avoid confusion between the two (e.g. `llmfit self-update` vs. `llmfit update`).
- No silent/automatic mutation of the binary without explicit user action.

### Open questions

- Where should the version-check endpoint live — GitHub Releases API directly, or a small hosted endpoint (mirroring `llmfit.axjns.dev`) to keep it lightweight and cacheable?
- Should the daily check be opt-in or opt-out by default?

---
Filed via automated workflow.