ci: attach verified release artifacts after authorization

[codeforester]

Summary

Prepare and validate release assets against the minimum and latest supported Base-CLI releases on Python 3.10 and 3.13, then attach the wheel, sdist, compatibility evidence, and SHA-256 manifest to an existing unpublished draft release. Document the version-pinned install path and draft-before-publish flow.

Issue

Refs #28

Validation

• Parsed the new GitHub Actions workflow YAML.
• git diff --check.

Notes

This is release preparation only: no tag, draft, or published release was created and the workflow has not run. A maintainer must separately authorize tag/draft creation, dispatch the workflow, verify immutable releases are enabled, inspect the assets, and publish the draft. Keep #28 open until the release, install path, checksums, and compatibility evidence are verified. Merge after #22 and #26 so the authoritative validation and version-identity gates are present.

[codeforester]

Multi-angle review of this PR (ci: attach verified release artifacts after authorization, addresses #28). Six findings, ranked by severity:

1. The final step targets the release by tag name, but the release was just verified as an unpublished draft — this will likely fail in practice. Line ~100 verifies DRAFT_RELEASE_ID (a numeric ID) is a valid unpublished draft for the tag, but the mutating step (line ~128, gh release upload "$RELEASE_TAG" ...) looks the release up by tag name instead of by that same ID. GitHub's tag-based release lookup only reliably matches published releases; drafts don't consume the tag the same way, and multiple drafts can share a tag_name. After 20+ minutes of matrix/build/validate work, this last step can fail outright ("release not found") for the exact draft it just confirmed exists — or, worse, silently attach the verified assets to the wrong draft if more than one shares the tag. Worth using the numeric ID consistently for both the verification read and the upload.

2. The new README install instructions point at a release that doesn't exist yet. README.md's "Install an existing release" section hardcodes a download URL for tag v0.1.0, but I confirmed (and three separate review passes independently confirmed) git tag -l and gh release list are both empty for this repo — no tag, draft, or release has been created. The PR's own description says to keep #28 open until the release is verified, but the README change ships to main as soon as this PR merges, independent of that. Anyone following the merged README gets an HTTP 404 until a maintainer completes the full manual release flow.

3. The base-cli compatible range is now hardcoded in (at least) three independent places. pyproject.toml's dependency declaration, this workflow's compatibility matrix (~lines 36-38), and a printf'd "Declared Base-CLI range" string (~line 123) that gets embedded verbatim into the publicly-attached COMPATIBILITY.txt release asset — plus the pre-existing copy in compatibility.yml. Four independent review passes flagged this same duplication. If the dependency range is ever bumped in pyproject.toml without updating the workflow copies, the matrix keeps testing a stale range and the published COMPATIBILITY.txt permanently misstates what's actually supported, with nothing to catch the drift.

4. The wheel/sdist that actually gets shipped is never checked for file-completeness — only the discarded one is. tests/package.sh (~line 108) builds its own sdist/wheel into a mktemp directory, validates required-file completeness against it, then deletes it via its EXIT trap. The workflow then runs a second, independent python -m build ... --outdir release-dist . (~line 110) to produce the artifacts that are actually checksummed and uploaded — and those are only twine check'd (metadata only, not file completeness). If the two builds ever diverge (stale .egg-info/SOURCES.txt, a MANIFEST.in edge case), a wheel missing required runtime files could ship as "verified" even though package.sh only validated a different, already-deleted artifact.

5. The new compatibility job drops a safety check present in the sibling compatibility.yml workflow. The existing supported job's "Confirm the wheel is the imported application" step (asserting base_cli_demo resolves from the installed wheel, not the checked-out source tree) isn't present here between installing the release wheel and running pytest. Without it, pytest could silently import from source instead of the release wheel, and the COMPATIBILITY.txt evidence attached to the immutable public release would falsely attest the wheel itself was validated.

6. docs/release-process.md's step 7 replaces the guarded basectl release publish with a manual git tag/push/gh release create --draft sequence, with two things quietly lost: there's no command re-verifying the working tree/commit is still the one validated in step 6 before tagging (an authorization-wait window with no automated guard), and the old doc's explicit disclaimer — that the tag-triggered release-package.yml run is not itself a publish action — was deleted with nothing replacing it. An operator could see that workflow go green after pushing the tag and assume the release is complete, skipping the manual asset-attachment dispatch this PR adds.