Support per-project Python version constraints

[codeforester]

Context

Base currently bootstraps Python tooling as part of setup and project setup, but projects should be able to declare the Python version they need instead of inheriting one global interpreter choice from Base.

Different projects may need different supported Python versions during migration, dependency compatibility work, or CI parity. Base should support that flexibility while still enforcing a supported compatibility window.

Proposal

Allow each Base-managed project to declare its required Python version or version range in project configuration, subject to Base-defined minimum and maximum supported versions.

Initial compatibility policy example:

• minimum supported Python: 3.10
• maximum supported Python: 3.13
• reject Python versions older than 3.10
• reject Python versions newer than 3.13 until Base explicitly supports them

Scope

• Define where a project declares its Python version requirement, likely in base_manifest.yaml or the existing setup/runtime configuration path.
• Make setup/check/doctor validate that the requested Python version is within Base's supported range.
• Make project setup select or report the correct interpreter for that project.
• Ensure diagnostics explain whether a failure is caused by an unavailable interpreter or an unsupported version.
• Update docs to explain the supported Python version window and project-level configuration.

Acceptance Criteria

• A Base-managed project can request a supported Python version such as 3.10, 3.11, 3.12, or 3.13.
• Base rejects project configuration that requests Python < 3.10.
• Base rejects project configuration that requests Python > 3.13.
• basectl setup, basectl check, or basectl doctor clearly report unsupported Python version requests.
• Tests cover supported versions, too-old versions, too-new versions, and the default behavior when no project-specific version is declared.
• Documentation describes the project-level Python version contract.

Notes

The exact min/max values can evolve, but Base should have an explicit policy boundary so projects get flexibility without drifting onto untested Python runtimes.