Rename picmaker.io to avoid shadowing the stdlib io module

[rfrenchseti]

Background

src/picmaker/io.py shadows the stdlib io module name. The module's docstring acknowledges this and instructs all internal consumers to use absolute imports (from picmaker.io import …), and every consumer in the codebase complies. There is no functional bug today — but a future contributor (or an automated refactoring tool) writing import io inside the picmaker package would silently pick up picmaker.io instead of the stdlib, which is surprising.

See CODEBASE_CRITIQUE.md §1 (Structure and layout, "Finding (Low) — picmaker.io shadows the stdlib io module name").

Proposed approach

Rename src/picmaker/io.py to src/picmaker/readers.py (or picmaker/fileio.py — either works; readers is shorter and matches the leaf module's primary purpose, which is the reader-cascade plus the output-file helpers). This is a breaking change for downstream callers who write from picmaker.io import X, so it should ride the same major-version bump that prunes the picmaker.picmaker BC shim (#11).

For one release after the rename, keep a thin picmaker/io.py shim that re-exports the new module and emits DeprecationWarning at import time, so downstream callers have a migration window.

Acceptance criteria

• src/picmaker/io.py renamed to src/picmaker/readers.py (or chosen alternative).
• All internal imports updated (pipeline.py, cli.py, __init__.py, picmaker.py, tests).
• One-release-only picmaker/io.py shim that emits DeprecationWarning and re-exports.
• docs/module.rst updated.
• CHANGELOG / RELEASING.md note added.
• After the deprecation cycle (next major), the shim is deleted in a follow-up PR.

Related

• CODEBASE_CRITIQUE.md §1 — original finding.
• #11 — the BC-shim pruning is a natural companion; rename and prune should land in the same major version.