feat: migrate build/release tooling to uv + python-semantic-release

[tomtranjr]

summary

Replaces Poetry + run-number versioning with the uv build backend and python-semantic-release (PSR) for Conventional-Commit-driven releases. Both tasks are done together because they rewrite the same files and PSR's build step is uv build.

• Build backend → uv_build. Sets module-name = "deployml" (dist is deployml-core) and excludes local .terraform artifacts from the sdist/wheel.
• Versioning → PSR derives version/changelog/tag/GitHub Release from commit messages. version_toml keeps pyproject.toml in sync. Baseline set to 0.0.60 (matches the latest tag + PyPI); this PR's feat: bumps the first automated release to 0.1.0.
• CI (release.yml) → uv-based test gate, then semantic-release version + uv publish via OIDC trusted publishing (no tokens). Replaces test-pypi.yml.
• Deletes poetry.toml; tracks uv.lock instead of ignoring poetry.lock.
• Adds tests/test_smoke.py; documents the uv workflow + commit conventions in contributing.md.

why 0.1.0 is safe on PyPI

0.1.0 > 0.0.60 (PEP 440) and was never uploaded, so it becomes the new "latest" with no collision. (PyPI only forbids re-uploading an existing version.)

verified locally

• uv build → wheel is 182KB (was 41MB before excluding a stray local .terraform provider binary); docker/, templates/, terraform/ assets all present, zero .terraform/tfstate junk.
• uv run pytest → 2 passed
• uv lock --check in sync; semantic-release restricts releases to main

heads-up / decisions made

• main has no unit tests. The real suite (test_doctor.py, test_helpers.py, test_platform_compat.py, …) is tracked only on dev and targets dev-only source (e.g. platform_compat.py doesn't exist on main), so it can't be ported cleanly. Added a minimal smoke test so the gate runs and passes; wire the full suite in once it lands on main.
• dev is 45 commits ahead of main with that unmerged work. Flagging per the "work off main" convention; not addressed here.

required before this can release (repo/PyPI settings, not code)

• PyPI trusted publisher: on pypi.org add a GitHub Actions trusted publisher for deployml-core (repo deployml-core/deployml, workflow release.yml). Required for OIDC uv publish.
• Branch protection: PSR pushes the release commit + tag to main. Allow the GITHUB_TOKEN/bot to bypass required-PR rules, or supply a PAT.
• Old PYPI_API_TOKEN / TEST_PYPI_API_TOKEN secrets are no longer used (per-push TestPyPI publishing was dropped).

test plan

• test job runs pytest on this PR
• after merge, release job publishes 0.1.0 to PyPI, tags v0.1.0, creates the GitHub Release + CHANGELOG.md

🤖 Generated with Claude Code

[lokeshmuvva]

Started reviewing this against the current uv and python-semantic-release docs. Leaving one question now on CI trigger scope; more to follow separately.

One thing not tied to a specific line: this PR targets main, but contributions here normally branch off dev and PR into dev (dev is ahead of main until a promotion). Was targeting main directly intentional for this migration, or should it be rebased onto dev?

[lokeshmuvva]

Question: both triggers here (push and pull_request) are scoped to branches: [ main ] only. Is folding dev in (e.g. branches: [main, dev] on the pull_request trigger) out of scope for this migration, or intentionally deferred? As-is, PRs into dev still get zero CI from this workflow — same gap the old test-pypi.yml had.