build: maintenance on the build and release path

[feanil]

Build and release maintenance, found by auditing the publish path end to end. Each commit stands alone.

Publishing

• PyPI trusted publishing — both publish jobs already requested id-token: write, so dropping the user/password pair lets gh-action-pypi-publish exchange the GitHub OIDC token instead. This also un-breaks attestations, which the action was silently ignoring: The workflow was run with the 'attestations: true' input, but an explicit password was also set, disabling Trusted Publishing.
• npm ci when publishing — every dependency in frontend-plugin-sample/package.json is "*", so the lockfile is the only thing pinning anything. npm install reconciles drift and carries on; npm ci installs the lock exactly and fails if it disagrees with the manifest. Worth having on the one build that becomes a published artifact.
• npm version --no-git-tag-version — a no-op today, added as intent documentation. npm gates git work behind a stat for .git in the package directory and does not walk up to the repo root, so a subdirectory package never commits or tags. The flag stops that resting on repository layout.
• Correct repository metadata — npm rewrote this field on every publish, so the registry metadata did not match the committed manifest. Adding directory also points the npmjs.com repository link at the subfolder.

The release could publish untested code

release.yml required only the backend test matrix. The frontend package had no CI at all: its first and only compile was inside publish_to_npm, which runs after the GitHub release is published and after both PyPI uploads. A syntax error in plugin.jsx would surface once two immutable PyPI versions and an immutable GitHub release already existed for a version with no npm package. The tutor plugin was likewise first built inside the release job.

This adds frontend-ci.yml and tutor-ci.yml (both pull_request + workflow_call) and makes release need all three, so nothing is tagged until every published package is known to build.

Two notes on those workflows:

• The tutor checkout uses fetch-depth: 0. setuptools-scm reads the version from git tags and tutor-contrib-sample declares no fallback_version, unlike the backend, so a shallow clone breaks it. This also exercises a path the release never takes, since the release passes SETUPTOOLS_SCM_PRETEND_VERSION.
• The frontend has no lint or test script, so compiling is the only check available. Adding those is a reasonable follow-up.

Correctness

• The tutor plugin shipped no license file. license-files = ["LICENSE*"] was declared but that directory had no LICENSE, so the glob matched nothing and setuptools built a wheel with no License-File: in METADATA and no dist-info/licenses/. The package claimed Apache-2.0 without carrying the text. Verified fixed by rebuilding.
• Python classifiers — the tutor plugin sets requires-python = ">=3.11" but only advertised 3.12.

Housekeeping

• CI concurrency — without a concurrency group GitHub never cancels superseded runs, so every push to a PR started another five-job matrix while the previous five ran to completion. The release path is unaffected by construction: in a called workflow github.workflow resolves to the caller's name, and with cancel-in-progress: false GitHub keeps only one pending run per group, so non-pull_request events key on github.run_id to give each release run a group of its own.
• Dead [wheel] universal = 1 — a Python 2 era flag on a package requiring >=3.12, and inert anyway since setuptools reads that option from [bdist_wheel].

Verification

actionlint passes on all workflows. Both new builds were run locally first: npm ci && npm run build compiles, and the tutor plugin builds sdist + wheel with twine check PASSED on both.

Follow-ups not in this PR

• The weekly Upgrade Python Requirements job has failed every run (4/4 in August) — the shared openedx/.github workflow runs make upgrade from the repo root and there is no root Makefile. Deferred pending a larger change.
• Dependabot only watches github-actions, so frontend-plugin-sample/package-lock.json gets no updates.
• codecov.yml sits in backend-plugin-sample/, but Codecov reads it from the repo root, .github/, or dev/ — the 100% patch target may not be applied. Unverified.
• Broken i18n make targets: Translation make targets point at a directory that does not exist #65.
• Within a release the frontend is still compiled after PyPI is written. The new gate makes that near-harmless since the same SHA already built green, but restructuring so everything builds before anything publishes would close it properly.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 93.04%. Comparing base (e0c2730) to head (bb471ca).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main      #66   +/-   ##
=======================================
  Coverage   93.04%   93.04%           
=======================================
  Files          16       16           
  Lines         503      503           
  Branches       18       18           
=======================================
  Hits          468      468           
  Misses         24       24           
  Partials       11       11           

Flag	Coverage Δ
unittests	93.04% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.