release: prepare 1.1.0 validation

[Mattsface]

Why

Prepare python-mlb-statsapi 1.1.0 for final release validation under #307.

The release branch already contains the implementation work for 1.1.0, including the new async API. This PR finishes the release-preparation layer: it updates package/version documentation for 1.1.0 and strengthens release validation so the built wheel and source distribution are verified for both sync-only and [async] installations.

The goal is to make sure the artifacts we publish match the documented 1.1.0 public contract without changing existing synchronous runtime behavior.

What

• Bump the package version from 1.0.1 to 1.1.0
• Add docs/releases/1.1.0.md
• Update README User-Agent/version references for 1.1.0
• Update HTTP transport documentation to reflect the current sync + async 1.1.0 surface while preserving historical 1.0 behavior
• Update release-validation tests to treat 1.1.0 as the current release and 1.0.1 as historical
• Strengthen scripts/validate_release.py so both the wheel and sdist are tested in clean environments for:
  • sync-only installation and public API behavior
  • installation with the [async] extra
  • AsyncMlb and AsyncMlbDataAdapter root imports
  • async lifecycle and cleanup behavior
  • strict_http=True default behavior
  • strict_http=False 1.x compatibility behavior
  • caller-owned HTTPX client ownership
  • versioned User-Agent behavior
• Require the async implementation/support files to be present in the source distribution
• Keep artifact smoke tests deterministic and offline using injected transports rather than the live MLB API

This PR does not redesign the async implementation, change dependency architecture, or intentionally change the existing synchronous public API.

Tests

GitHub Actions passes on the branch:

• Offline tests — Python 3.10
• Offline tests — Python 3.11
• Offline tests — Python 3.12
• Offline tests — Python 3.13
• Offline tests — Python 3.14
• Sync-only installation
• Build and validate package

The build validation also successfully:

• built the release artifacts
• ran scripts/validate_release.py
• validated clean sync and async-extra artifact installs
• ran Twine checks against the built distributions

All artifact smoke validation remains offline and does not contact the live MLB API.

Risk and impact

Risk level: Normal

The package runtime implementation is not being changed here, which limits direct regression risk for users. However, this PR makes a substantial change to the release-validation tooling and expands the checks applied to the actual wheel and source distribution, so it is more than a documentation-only or minimal-risk release bump.

If something goes wrong with this PR, the primary impact would be to the release process rather than normal library runtime behavior. A validation bug could incorrectly reject a valid 1.1.0 artifact or, more importantly, fail to catch a packaging problem before publication.

The most important compatibility requirement remains unchanged: existing 1.0.x synchronous users should require no code changes when upgrading to 1.1.0.

Closes #307

[Mattsface]

@claude do a pass

[claude]

Claude finished @Mattsface's task in 2m 37s —— View job

---

Review complete

Todo list

• Gather context (read diff, CLAUDE.md, changed files)
• Review README.md changes
• Review docs/http-transport.md changes
• Review docs/releases/1.1.0.md
• Review pyproject.toml version bump
• Review scripts/validate_release.py changes
• Review tests/test_release_validation.py changes
• Post final review feedback

Summary

This is a well-scoped, additive release-prep PR — no runtime behavior changes, purely docs + version bump + release-validation tooling. I diffed against origin/release/1.1.0 and cross-checked every claim against the actual source (mlbstatsapi/async_mlb.py, async_mlb_dataadapter.py, _async_transport.py, __init__.py). Everything I checked is internally consistent:

• Version bump (pyproject.toml, README, docs/http-transport.md) — all now say 1.1.0 / python-mlb-statsapi/1.1.0 consistently; no stale 1.0.1 references left in current-release docs.
• docs/releases/1.1.0.md — claims about AsyncMlb/AsyncMlbDataAdapter (lazy import via __getattr__ in mlbstatsapi/__init__.py), proxy env var support, and retry-policy sharing all match the actual implementation in _async_transport.py.
• docs/http-transport.md — updated links (releases/1.1.0.md, async.md#custom-httpx-client) resolve to real files/anchors; I verified docs/async.md's headers include Custom HTTPX client and Environment proxies.
• scripts/validate_release.py — the new _check_async_clean_install / ASYNC_SMOKE_TEST_SOURCE correctly exercise AsyncMlb's real constructor signature, _client/_mlb_adapter_v1 internals, and aclose() idempotency (all verified against async_mlb.py). REQUIRED_SDIST_PATHS now lists all the async support modules that actually exist in mlbstatsapi/.
• tests/test_release_validation.py — the _classify_command split into sync-install/async-install/sync-smoke/async-smoke is exercised by new parametrized failure-path tests for both wheel and sdist, and the doc-consistency tests (CURRENT_RELEASE_NOTES, HISTORICAL_RELEASE_NOTES, User-Agent/Python-version cross-checks) were correctly updated to treat 1.1.0 as current and fold 1.0.1.md into history.

No correctness issues found. Two minor, non-blocking observations:

1. scripts/validate_release.py duplicates the *_STRICT_DEFAULT_MESSAGE constants both at module scope and inside the embedded ASYNC_SMOKE_TEST_SOURCE/SMOKE_TEST_SOURCE strings (necessary since those run as standalone subprocesses), but this is already guarded by test_async_smoke_test_labels_reverted_strict_defaults, so drift would be caught — no action needed.
2. I was unable to execute pytest in this sandboxed environment (command execution requires interactive approval not available here), so I verified correctness by static cross-referencing against the implementation rather than running the suite. The PR description states CI is green across all 7 jobs, which covers this.

Nice to have but not required: this PR doesn't touch CHANGELOG-style files (none exist in this repo) or poetry.lock (root package version isn't tracked there), so nothing further needed on that front.