CCL-467: fix CI coverage target and make publishing tag-driven

[atokayev]

Summary

• CI has never measured anything. python.yml ran pytest --cov={{packageName}} — an unrendered Mustache template. Coverage emitted CovReportWarning: No data to report and the job still exited 0. Now --cov=platform_api_python_client.
• Publishing is now driven by the tag, not by a GitHub Release. The old release: published trigger decoupled the published artifact from the release name. Run 29043124220 fired from the release tagged v4.21.1 but ran against ref v4.20.0, published 4.20.0, and left 4.21.1 permanently absent from PyPI. Seven tags never reached PyPI in total.
• Added a tag/version gate. The job builds first, then asserts the tag equals the version of the distribution actually produced, and fails closed on 0 or >1 sdists. This would have hard-failed the 4.21.1/4.20.0 mismatch instead of silently shipping the wrong version.
• Added twine check --strict as a metadata regression guard, plus environment: pypi and contents: read, and bumped the deprecated checkout@v3 / setup-python@v3 (and setup-python@v4 in python.yml).
• Deleted .travis.yml.

Notes for reviewers

The tag filter matches both spellings on purpose. CCL-467 specifies tags: ["v*"], but 4 of the 31 existing tags carry no v prefix (3.2.5–3.2.8). A tag matching no pattern produces no run, no error and no alert — the exact silent-skip this workflow exists to remove. Patterns are ["v*", "[0-9]*"]; all 31 existing tags match.

The version check deviates from the snippet in CCL-467. That snippet reads tomllib.load(...)['project']['version'], but pyproject.toml has no [project] table — it declares [tool.poetry] while building with the setuptools backend (which reads setup.py). The snippet raises KeyError: 'project' and would have failed every release. Reading the version from the built distribution is backend-agnostic and keeps working after CCL-470 moves the project to PEP 621.

twine check --strict passes on the current tree, so contrary to the ticket it would not have caught the placeholder PyPI description — it validates description rendering, not metadata completeness. It is a regression guard here; CCL-470 is what actually fixes the listing. Importantly this means the gate does not block CCL-471.

.gitlab-ci.yml was deliberately kept, departing from CCL-467's third acceptance criterion, which asks for both files to be deleted. The commit-status test below is conclusive for Travis (a GitHub App that always reports) but not for GitLab, since a one-way mirror to an internal GitLab need not report back to GitHub. Left byte-identical pending confirmation of whether such a mirror exists.

⚠️ CCL-468 will revert python.yml unless it is extended. All three files this PR touches are generator-owned and tracked upstream at CentML/platform:client/python/platform_api_python_client/, including a .github/workflows/python.yml that still contains the {{packageName}} bug. They survive today only because sync_client.yml uses globs that skip dot-paths. CCL-468 proposes cp -r .../., which does copy dotfiles and would silently restore the broken workflow and resurrect .travis.yml. That ticket must additionally git rm the upstream .github/workflows/python.yml and .travis.yml and add them to the platform-side .openapi-generator-ignore — ignoring alone is insufficient because the upstream copies are already tracked. A warning to this effect is in the python.yml header.

Out of scope, left alone deliberately: .openapi-generator/FILES still lists the deleted file (already stale by 26 entries; owned by CCL-468), and LICENSE / CHANGELOG.md / real tests (CCL-470, must land upstream).

Testing

• actionlint .github/workflows/{publish,python}.yml — pass
• python -m build --sdist --wheel — pass, platform_api_python_client-4.28.0.{tar.gz,whl}
• twine check --strict dist/* — pass, both distributions
• pytest --cov=platform_api_python_client — 203 passed, TOTAL 47% (previously No data to report, exit 0)
• same, with a deliberately failing test added — 1 failed, 203 passed, exit 1 (red build confirmed; canary not committed)
• tag gate, GITHUB_REF_NAME=v4.28.0 → exit 0; 4.28.0 (no prefix) → exit 0; v9.9.9 → exit 1; v4.28.0-rc1 → exit 1; 0 sdists → exit 1; 2 sdists → exit 1
• all 31 existing tags checked against the trigger patterns — 0 unmatched
• gh api .../commits/{sha}/status over 2024-06 → 2026-09 — 0 commit statuses ever, and gh api .../actions/workflows lists only the two workflow files plus GitHub's dynamic Dependabot/CodeQL entries, so nothing consumed .travis.yml

Not verified: the PyPI trusted-publisher settings are not visible to me. Adding environment: pypi is inferred safe because 24 releases published with no environment: set, so the publisher entry cannot be pinning one. Note GitHub auto-creates the environment without protection rules — required reviewers must be added in repo settings for the approval gate to be real. The workflows themselves have not yet executed on CI.

Linear

• CCL-467

[atokayev]

@codex review