Sync dev tooling between master and v0.2-integration

[R7L208]

Context

After aligning the core build pipeline (PEP 517/518 with hatchling) across both branches in #455 and #454, the surrounding dev tooling still diverges. This should be unified before merging v0.2-integration into master to avoid conflicts and inconsistency.

Current State

Area	master	v0.2-integration
Version source	CURRENT_VERSION = "0.1.30" constant	Git tag via git describe
Makefile	Newer (make setup, make quality, make ci, make doctor)	Older (simpler targets)
.env.versions	Yes (pins hatch version centrally)	No
tox.ini	Removed	Still present (updated to use hatch build)
CI install	make setup → reads .env.versions	pip install hatch 'virtualenv<21' directly

Proposed Outcome

Version source

Recommendation: Keep git-tag approach for v0.2-integration, adopt it on master at merge time.

Pros	Cons
Single source of truth — version derived from release tags automatically	Requires git history (full clone) in CI; fails in shallow clones without tags
No manual version bumps to forget	Slightly more complex than a hardcoded constant
Already working on v0.2-integration

Makefile

Recommendation: Port the master Makefile to v0.2-integration.

Pros	Cons
make setup, make quality, make ci, make doctor are useful for onboarding and local dev	Requires updating v0.2-integration CI workflow to use make setup / make quality
Consistent developer experience across branches	Minor churn on an integration branch
Reduces merge conflicts when v0.2-integration merges to master

.env.versions

Recommendation: Add .env.versions to v0.2-integration.

Pros	Cons
Pins tool versions in one place — CI and local dev stay in sync	One more file to maintain
Avoids "works on my machine" drift between hatch versions
Already proven on master's CI

tox.ini

Recommendation: Remove tox.ini from v0.2-integration.

Pros	Cons
Hatch is the sole build/test orchestrator — no dual config to maintain	Anyone still using tox directly would need to switch
Eliminates a source of config drift (tox.ini vs pyproject.toml)
Matches master which already removed it

CI install approach

Recommendation: Adopt make setup (reading .env.versions) on v0.2-integration, matching master.

Pros	Cons
Centralized version management — update one file, CI and local dev both change	Depends on .env.versions being added first
No hardcoded pip install lines scattered across workflow YAML	Slightly more indirection
Consistent with master — reduces merge friction

Definition of Done

• v0.2-integration Makefile matches master (with any v0.2-specific adjustments)
• .env.versions added to v0.2-integration
• tox.ini removed from v0.2-integration
• v0.2-integration CI workflow uses make setup / make quality
• Version sourcing strategy decided and documented
• CI passes on v0.2-integration after changes