Harden Eventful for production releases

[aidankhogg]

Outcome

Moves Eventful from an undocumented pre-alpha posture to a bounded, production-capable 0.3 release candidate. This deliberately does not claim exactly-once delivery or a frozen 1.0 API.

Runtime hardening

• incorporates the deterministic FastAPI/Starlette lifecycle work from Expand ASGI adapter lifecycle coverage: close on failed startup, tests, and docs #10
• closes adapter-owned buses exactly once after normal shutdown, failed startup, or lifespan exceptions
• documents process isolation, worker boundaries, and ownership behavior
• expands adapter lifecycle and concurrency coverage

Release and supply-chain hardening

• adds tag-only trusted PyPI publishing through the protected pypi environment
• requires tag/package version agreement
• creates build-provenance attestations
• adds CodeQL, pip-audit, and weekly dependency/action updates
• constrains workflow permissions, concurrency, and timeouts
• bounds supported optional dependency major versions
• adds project metadata URLs and raises the package status to beta

Operational contract

• adds a production-readiness matrix for core, Redis, PostgreSQL, file, and ASGI use
• records delivery/durability boundaries, operator responsibilities, and explicit non-guarantees
• expands the security and deprecation policies
• establishes a 75% coverage floor

Verification

Verified locally on CPython 3.13.14:

• Ruff: passed
• strict mypy: passed (38 source files)
• pytest: 120 passed, 18 expected external-service skips
• coverage: 76.03% (75% floor)
• annotation and public-docstring checks: passed
• wheel and sdist builds: passed
• MkDocs strict build: passed

CI additionally exercises Python 3.13 and 3.14 and service-backed Redis/PostgreSQL installations from built artifacts.

Supersedes #10 because its complete ASGI lifecycle change set is included here.

[github-advanced-security]

You are seeing this message because GitHub Code Scanning has recently been set up for this repository, or this pull request contains the workflow file for the Code Scanning tool.

What Enabling Code Scanning Means:

• The 'Security' tab will display more code scanning analysis results (e.g., for the default branch).
• Depending on your configuration and choice of analysis tool, future pull requests will be annotated with code scanning analysis results.
• You will be able to see the analysis results for the pull request's branch on this overview once the scans have completed and the checks have passed.

For more information about GitHub Code Scanning, check out the documentation.