Generate a Python version requirement for requirements.txt-only projects

[tdstein]

Problem

For Python projects that contain requirements.txt but do not contain a
.python-version, pyproject.toml with project.requires-python, or
setup.cfg with python_requires, rsconnect-python generates a manifest with
only the exact local interpreter version:

{
  "python": {
    "version": "3.11.9"
  }
}

It does not generate environment.python.requires.

This is likely the most common project layout for Python content deployed to
Posit Connect. The generated manifest therefore relies on the legacy
python.version field rather than expressing the content's compatibility as a
version constraint. This can prevent Connect from rebuilding content with a
different available Python version, particularly when exact version matching
is enabled.

Current behavior

Environment.create_python_environment() detects a requirement only from:

1. .python-version
2. pyproject.toml → project.requires-python
3. setup.cfg → python_requires

When none is present, python_version_requirement remains None.
Manifest consequently omits environment.python.requires, while
python.version is populated with the full version of the interpreter used for
environment inspection.

Proposed behavior

When no explicit Python requirement is found, derive a major/minor-compatible
requirement from the inspected interpreter and include it in the manifest.

For example, packaging with Python 3.11.9 could produce:

{
  "python": {
    "version": "3.11.9"
  },
  "environment": {
    "python": {
      "requires": "~=3.11.0"
    }
  }
}

An explicit requirement from .python-version, pyproject.toml, or
setup.cfg should continue to take precedence.

The exact fallback constraint syntax is open for discussion, but it should
allow Connect to select an available compatible patch release while preserving
the deployed interpreter's major/minor version.

Motivation

• requirements.txt-only projects are common.
• Users should not need to add unrelated packaging metadata solely to obtain
  appropriate Python version matching.
• Connect should be able to rebuild content with another compatible Python
  installation when the original patch release is unavailable.
• This would make the default behavior consistent with the intent of
  environment.python.requires.

Related work

• Support environment.python.requires option in manifest #648 added support for environment.python.requires when a constraint is
  explicitly available.
• .python-version is not necessarily a version specifier (per PEP 440) and thus cannot necessarily be used for environment.python.requires #659 addressed adapting .python-version values into version constraints.
• posit-dev/connect#43572 contains a recent discussion of Connect rebuilding
  content after supported Python installations change.

Acceptance criteria

• A Python project containing only requirements.txt gets an
  environment.python.requires fallback derived from the inspected
  interpreter.
• The fallback matches compatible patch releases within the same major/minor
  version.
• Explicit project constraints continue to override the fallback.
• Generated manifests retain python.version for backward compatibility.
• Tests cover requirements-only projects and explicit-constraint precedence.