CI: cache Galaxy collections + pip, and bound the molecule job

[thiras]

Two small robustness/speed items on the CI workflows, both surfaced while landing #50.

1. Nothing caches the Galaxy collections or pip

make deps resolves and installs from galaxy.ansible.com on every run, in both ci.yml (galaxy-build, ansible-lint) and molecule.yml, with no cache and no retry. molecule.yml also pip installs molecule + ansible + ansible-lint fresh each run.

This is not hypothetical: the galaxy-build job on #50 failed on a transient upstream error —

[WARNING]: Skipping Galaxy server https://galaxy.ansible.com/api/. Got an unexpected error
when getting available versions of collection community.crypto: <urlopen error [Errno 104]
Connection reset by peer>
make: *** [Makefile:9: deps] Error 1

— and passed unchanged on re-run. Any job that calls make deps can fail this way at any time.

Proposal: actions/cache on ansible/collections keyed on hashFiles('ansible/requirements.yml'), plus cache: pip on actions/setup-python. Cuts the exposure to that flake class and takes time off every affected job. (#50 already removed one of the two make deps calls in the molecule workflow, since the Make target now owns the prerequisite.)

2. The molecule job has no timeout-minutes

.github/workflows/molecule.yml sets cancel-in-progress: true but no job timeout, so a hung scenario burns the 360-minute default. Worth pinning to something like timeout-minutes: 45 — the job currently runs in ~4m41s at JOBS=3.

Note some branch-protection configurations treat a cancelled check as "not failed", so an unbounded hang plus cancel-in-progress is a slightly worse failure mode than it first looks.