Preflight git-annex and git on PATH at CLI entry, beside the venv check

Every command already refuses to run unless it is in the campaign's own venv and the venv matches the lock. It does not check that `git-annex` is on `PATH`, and on a cluster that ships none (Unity: it is provisioned into a workspace and put on `PATH` by a site script) a fresh shell with the venv active but the site script unsourced gets deep, late failures instead of a refusal:

- `add-dataset --study URL`: the member clone dies at the `.gitmodules` smudge with `git-annex: not found`, after datalad has already created the directory, so the next attempt is refused as "already exists".
- `iterate`: a merge tick dies inside `babs merge` with a datalad traceback ending in `No working git-annex installation >= 10.20230126`, after the tick has taken the lock and read every cell.

Both happened on the 2026-08 Unity run, twice each, and the fix each time was `source site-env.sh` and rerun. Ask: preflight `git-annex` (and `git`, 2.25 or newer, per the cluster-config contract) at CLI entry alongside the venv check, and refuse with one line naming what is missing, before any state is touched. The version floor can be whatever babs declares.

Related: the cluster config's `script_preamble` already has to put the same tools on the job's `PATH`; this is the login-side half of that contract.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Start at the CLI entry point beside the existing venv and lock checks, then review the cluster config's script_preamble contract for the required PATH tools. Verify that add-dataset and iterate refuse before touching state, with one-line errors naming a missing git-annex or an unsupported git version.

Written by the indexing model from the issue text.