make the local venv match CI

[vpzed-dev-lux]

Why

CI and a workstation ran different software, and the difference decided lint results:

	local (before)	CI (before)
ansible	ansible==14.3.1, 244 MB of collections in site-packages	pipx install ansible-core, unpinned
ansible-lint	same venv, ==26.8.0	pipx install ansible-lint, unpinned, with its own second ansible-core
collections	whatever ansible 14.3.1 shipped (45 namespaces)	exactly ansible/requirements.yml, in $RUNNER_TEMP
Python	3.14.7, uv-managed	the runner's

So ansible/requirements.yml was authoritative in CI and decorative locally: a task using an unlisted community.* module passed on a workstation and failed in CI — which is how PR #22 went red.

Both sides now build the same environment from the same two files: requirements.txt for Python, ansible/requirements.yml for collections.

Not done, deliberately: giving CI the full ansible package. That would hand both sides collections nobody pinned and make ansible/requirements.yml inert — the guarantee worth having is that a missing pin fails everywhere.

What changed

• requirements.txt — ansible out, ansible-core stays; regenerated with uv pip freeze the way the file was originally made. Only other movement is platformdirs 4.11.4 → 4.11.5 from the fresh resolve. black and yamllint are ansible-lint dependencies, so they survive.
• scripts/install-collections.sh (new) — the one way collections get installed, run by both environments. Installs into the ANSIBLE_COLLECTIONS_PATH its caller names, --force so a copy elsewhere in galaxy's search path cannot turn it back into a "Nothing to do" no-op.
• tofu.env — exports ANSIBLE_COLLECTIONS_PATH=$PWD/.venv/share/ansible/collections. Under .venv/ so recreating the venv takes the collections with it; setting it also replaces ansible's defaults, which is the point.
• .github/workflows/validate.yaml — drops pipx for uv venv --python 3.14 --managed-python + uv pip install -r requirements.txt (the README's own commands), .venv/bin onto $GITHUB_PATH, and the same script. The path is a job-level env: entry built from github.workspace; runner is unavailable in that block, which is what produced the invalid-workflow run on golden image cutover #22.
• scripts/check-ansible.sh — new first check: every pin in ansible/requirements.yml installed at exactly the pinned version, naming install-collections.sh when not. Without it a stale collection shows up only as an opaque ansible-lint failure three checks later.
• Docs — README.md (setup steps, tree, the "Collections are pinned" bullet), CLAUDE.md (what tofu.env exports, the venv/collections relationship), and the header of ansible/requirements.yml, which previously described this change as the fix to make.

Verification

ok    collections (2 pinned)
ok    inventory (1 host(s))
ok    site.yaml syntax
ok    ansible-lint

• tofu validate and tofu fmt -check -recursive pass; tofu plan reports No changes — no VM is touched by this.
• ansible-doc community.general.timezone resolves out of .venv/share/ansible/collections, so the module is found at execution time, not just by lint.
• Negative test: temporarily pointing a base task at community.docker.docker_host_info now fails locally with syntax-check[unknown-module], which is the whole claim — before this, it would have linted clean here and failed in CI. Reverted.