docs: remove stale tox references left over from the uv migration

[hf-kklein]

What

Cleans up stale tox references left over from the uv migration. Both create_env_file.py module docstrings still claimed the script "is used in all tox environments except the linting environment", which is no longer true (there is no tox.ini).

Closes #278

Changes

• src/borm/db/postgresql_db/create_env_file.py — reworded to describe the real caller: it runs as a CI workflow step (uv run python -m borm.db.postgresql_db.create_env_file in unittests.yml, coverage.yml, integrationtests.yml, python-publish.yml) and is documented for local setup in the README.
• src/borm/db/mysql_db/create_env_file.py — this variant has no CI caller (the MySQL backend is not wired into any workflow, unlike PostgreSQL). Per the issue's requirement not to give it "a docstring claiming a caller it does not have", reworded it to describe manual/local invocation (it has a __main__ block: uv run python -m borm.db.mysql_db.create_env_file).

Open decision (see comment)

The issue offered "wire it up or delete it" for the MySQL variant. I did neither, because deletion looked wrong and wiring-up is a scope decision — details in the PR comment below.

Deliberately untouched

• .tox/ in .gitignore and any historical records under docs/**/plans|specs (per the sweep convention).

🤖 Generated with Claude Code

[hf-kklein]

Open decision: what to do with the MySQL create_env_file (and the MySQL backend generally)?

Issue #278 asked me to either wire up src/borm/db/mysql_db/create_env_file.py next to the PostgreSQL one, or delete it. I did neither in this PR and instead only corrected its docstring, because both options are judgment calls I'd rather leave to you:

Current facts

• postgresql_db/create_env_file.py is invoked in CI (unittests.yml:22, coverage.yml:22, integrationtests.yml:22, python-publish.yml:34/53/77) and documented at README.md:39.
• mysql_db/create_env_file.py is not invoked by any workflow. But the mysql_db package is not dead: it ships alembic.ini, migrations/, docker-compose.yaml, .env.example, auxiliary.py, and a __main__ block — a full parallel backend to postgresql_db.

So deleting just create_env_file.py looked wrong (it would break local MySQL setup while leaving the rest of the backend), and wiring it into CI is a scope decision (it implies running a MySQL service in the affected workflows).

Question — please pick one:

1. Keep as-is (local-only helper; my docstring reword already reflects this) — nothing more to do here.
2. Wire MySQL into CI like PostgreSQL — I'll add the uv run python -m borm.db.mysql_db.create_env_file step + a MySQL service to the relevant workflows in this PR.
3. Remove the MySQL backend entirely (not just this file) — I'll open a separate PR deleting src/borm/db/mysql_db/**, since that's a bigger change than a tox-cleanup.

Defaulting to option 1 unless you say otherwise.

[Copilot]

Pull request overview

This pull request removes outdated tox references from the module docstrings of the create_env_file.py helpers after the repository’s migration to uv, aligning the documentation with how these scripts are actually invoked.

Changes:

• Updated PostgreSQL create_env_file.py docstring to describe its CI workflow invocation (uv run python -m ...) and local usage documentation.
• Updated MySQL create_env_file.py docstring to avoid claiming a CI caller and instead describe manual/local invocation.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File	Description
src/borm/db/postgresql_db/create_env_file.py	Rewords docstring to replace stale tox wording with CI workflow + README-based usage.
src/borm/db/mysql_db/create_env_file.py	Rewords docstring to describe manual invocation and explicitly note lack of CI usage.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[hf-krechan]

Reviewed as part of the stale-tox-reference cleanup. Approved.

Comment/doc-only change with no behavioural effect. I verified the replacement text is actually correct rather than merely plausible:

• The new docstrings make specific factual claims and both hold up: the PostgreSQL variant is invoked in exactly unittests.yml, coverage.yml, integrationtests.yml and python-publish.yml, and the MySQL variant is invoked by nothing in the repo — so "not currently invoked by any CI workflow" is accurate, not a guess.
• CI is green.