Add an lfs input to the reusable CI workflows

[MattFisher]

Problem

A repo whose tests read LFS-tracked fixtures cannot currently use these
workflows. actions/checkout runs without lfs, so the working tree gets
130-byte pointer files, and the failure surfaces as whatever the reading
library says about malformed input — nothing anywhere in the output mentions
LFS.

Found while setting up azai-portfolio, whose test fixtures are LFS-tracked
PDFs. The symptom there was:

E  pymupdf.mupdf.FzErrorFormat: code=7: no objects found

which took a log dig to trace back to LFS.

Change

Both python-ci.yml and node-ci.yml gain an lfs boolean input, passed
through to actions/checkout.

Defaults to false, so nothing changes for existing consumers: an LFS
pull costs bandwidth against the account quota on every run, and most projects
have nothing in LFS to fetch.

Added to node-ci.yml as well as python-ci.yml for symmetry — a frontend
with LFS-tracked assets has the same problem, and the two workflows already
mirror each other's inputs.

Note on delivery

Consumers pin @v1, so this reaches them when a release is published and
bump-v1.yml moves the tag — merging alone is not enough.

Possible follow-up, not in this PR

Scaffolding with use_frontend=true produces a repo whose frontend job is
red from the first commit, because the template creates biome.json but no
skeleton in frontend_dir. Worth deciding whether the template should
scaffold a minimal package.json/tsconfig.json there, or whether red CI
until the frontend exists is the intended signal. Happy to do either.

Posted by Claude Code on Matt's behalf.