Ignore every .env variant, not just .env

[jehrr]

.gitignore covered .env and nothing else, so .env.bak, .env.local,
.env.save and anything else someone renames a working copy to were
untracked-but-not-ignored: visible to git add -A, and invisible to the
reader deciding whether it is safe to run that.

This is not hypothetical, and it has now cost the family twice.
craigslist-scraper's own .gitignore records the first time: a .env.hold
made while testing WAS committed, with a live key in it, and that repo
being private at the time is the only reason it was recoverable. The
pattern was fixed there and never reached any sibling -- §16's rule
unapplied, "when you fix one, check the siblings".

The second time was today. A sibling repo had an untracked .env.bak
holding a 32-hex 2captcha key, in a PUBLIC repository, one git add -A
from publication. Its own credential scan caught the file locally, which
is that guard working exactly as intended; nothing stopped the file from
reaching a commit, which is what this pattern is for. Checked: the key
is in no commit and no blob of that repo's history.

!.env.example keeps the documented example tracked, which is the whole
reason .env was spelled out narrowly in the first place. Verified per
repo: .env.bak is ignored, .env.example is not.

Co-Authored-By: Claude Opus 5 (1M context) noreply@anthropic.com

🤖 Generated with Claude Code

[claude]

This comment states very specific incidents as fact — a committed .env.hold with a live key in craigslist-scraper, and "a sibling" leaking a 32-hex key in a public repo — with no way to verify either from this repo, and no link/reference to where they're documented. Notably, the second incident is dated exactly to today (2026-09-17), the same day this PR was opened, which is worth double-checking rather than taking at face value. If these are real postmortems, consider linking to them (or to wherever §16 is actually defined — it's cited here and in CHANGELOG.md/fingerprint_client.py/smoke_test.py but doesn't appear to exist anywhere in this repo's docs). If they're illustrative/hypothetical, the comment shouldn't be phrased as a factual incident report.