Update workflow to use PyPI Trusted Publisher framework

[ajnelson-nist]

Workflow updates were adapted from CDO-Utility-Local-UUID PR 9.

References:

• https://docs.pypi.org/trusted-publishers/
• Update workflow to use PyPI Trusted Publisher framework Cyber-Domain-Ontology/CDO-Utility-Local-UUID#9

[ajnelson-nist]

This PR is ready for review and merge. (The longer CI steps run on affected parts of the CI workflow.)

[plbt5]

I cannot review this one; apparently I'm not assigned as reviewer.

[vulnmaster]

Reviewed by Vulnmaster with the help of GPT 5.6 High

Thanks for moving this project toward PyPI Trusted Publishing. Replacing the long-lived API token with OIDC is a worthwhile security improvement. I see several issues that should be addressed before merge:

1. Publishing is no longer gated by CI. The previous upload occurred at the end of the CI job, after pre-commit, tests, package building, and twine check. The new publishing workflow is independent and does not run or depend on the test suite. Please consider making the publishing job depend on successful test and package-build jobs.

2. The package is built inside the OIDC-authorized job. The job installs dependencies and invokes the Python build backend while holding id-token: write. PyPA recommends separating building from publishing so build dependencies or project build code cannot request the publishing credential. Please build and check the distributions in a non-privileged job, upload them as an artifact, and have the publishing job only download and publish that artifact.

3. contents: read is not declared for checkout. Because the job-level permissions block specifies only id-token: write, all unspecified GITHUB_TOKEN permissions are set to none. Please give the build job contents: read. The final publishing job should retain only id-token: write.

4. The release trigger changed from published to released. Unless stable-only behavior is intentional and documented, please retain types: [published] to preserve the existing release behavior and handle releases published from drafts consistently.

Please also confirm that the release GitHub environment will be created with appropriate protection rules and that the PyPI Trusted Publisher is configured for this repository, publish.yml, and the release environment.

My preferred structure would be:

• test job
• package-build job that depends on tests and uploads the checked distributions
• publishing job that depends on the package-build job, has id-token: write, downloads the distributions, and invokes pypa/gh-action-pypi-publish