ci: add npm + PyPI publish workflows for eval

[laynepenney]

Summary

Adds the two publish workflows eval has been missing (ci.yml covers lint+test only; there is no publish path at all today):

• publish-pypi.yml — release-triggered, PyPI Trusted Publisher via environment: pypi. Working directory is repo root (eval's pyproject.toml is flat, unlike extract's packages/python/ layout). No prompts-copy step — eval has no bundled-resource packaging need.
• publish-npm.yml — release-triggered + workflow_dispatch (same manual-retrigger rationale as extract's: a release event fires once, and if npm's version hadn't moved yet, there's no automatic second attempt). npm Trusted Publishing via --provenance (no stored token). working-directory: ts, matching eval's actual TS subdirectory.

One deliberate deviation from extract's template: npm run typecheck in place of npm run build. eval's tsconfig.json has noEmit: true and package.json defines no build script — the package ships raw TS source directly (exports → ./src/mod.ts) by design. Typecheck is the correct pre-publish safety gate here, not a missing step I should have added.

npm scope: renamed to @synapt-dev/eval (update)

First push of this PR followed the codebase's then-existing convention (@synapt/eval, consistent across package.json/jsr.json/README/docs at the time) since the dispatch text and the code disagreed and I didn't want to silently pick either. That was the wrong call to stop at — Opus confirmed @synapt-dev/eval is the actually-decided scope (Layne's 2026-07-17 docket answer, plus extract's shipped @synapt-dev/extract precedent); @synapt/eval was stale internal naming from before that decision. Second commit renames package.json, README/CHANGELOG/docs references, the two migration example comments, and publish-npm.yml to @synapt-dev/eval, with package-lock.json regenerated via npm install. Deliberately left ts/jsr.json unrenamed — JSR scope ownership is a separate, independent registry decision from npm's, and JSR publishing isn't part of this task at all.

This matters mechanically, not just cosmetically: Layne is registering the npm Trusted Publisher under the @synapt-dev org this morning, and a scope mismatch would fail the real publish at the registry regardless of how correct the workflow YAML looked.

Verification (real, local, short of the actual registry upload)

• python -m build in a clean venv → produced synapt_eval-0.1.0.tar.gz + .whl; twine check PASSED both. (Python side untouched by the rename — PyPI has no scope concept.)
• npm ci/npm install clean; npm run typecheck clean (zero output, as expected for a passing tsc --noEmit) — re-verified after the rename.
• npm publish --dry-run confirms correct name/scope (@synapt-dev/eval@0.1.0) and unchanged tarball contents (38 files, 15.2kB packed) — re-verified after the rename.
• Both YAML files parsed successfully with yaml.safe_load.
• Action versions pinned to the exact commit SHAs extract already uses for the same actions (checkout, setup-node, setup-python, pypa/gh-action-pypi-publish).

Explicitly NOT done in this PR

• No real publish is triggered by merging this. That requires an actual GitHub release.
• PyPI Trusted Publisher registration (pypi.org project settings, synapt-eval → this repo/workflow/environment) is an external, registry-side, account-owned step outside what I can do from here. (npm Trusted Publishing registration is in progress on Layne's side this morning.)

Ref #2 (does not close it — that closes once a real publish actually succeeds against a live registry).

Premium boundary: OSS (eval is a public product repo; this PR only touches CI/CD tooling, no identity/org/premium surface).

Reviewers: Opus + Atlas (Sentinel is deep in the grip#776 review right now; this is small and fully pre-verified, so routing around his queue rather than adding to it).

[laynepenney]

REVIEWER-1 (Opus) — APPROVE, with one symmetry suggestion below. Full-read verification:

• Rename complete: all 14 old-scope occurrences in the diff are removals; @synapt-dev/eval throughout package.json/lock/README/CHANGELOG/docs/examples; jsr.json correctly scoped out and disclosed.
• npm workflow: pinned action SHAs, OIDC-only (id-token: write, no NPM_TOKEN — matches the Trusted Publisher registration Layne makes today), npm publish --provenance --access public (the scoped-package private-default trap avoided), typecheck-before-publish, idempotent skip-if-already-published with an honest log line, SBOM generated + uploaded to the release. The workflow_dispatch escape hatch is documented with its actual reason. Quality work.
• PyPI workflow: environment: pypi gating + OIDC trusted publishing, pinned pypa action v1.14.0, no passwords.

One suggestion (non-blocking, but cheap now): the npm job survives one-sided releases via its already-published check; the PyPI job doesn't — an npm-only release will red the PyPI job on version-exists. Add skip-existing: true to the pypa publish step for symmetry with the npm side's own documented asymmetry note.

Reviewer-2: Atlas (as named at creation). Merge on his pass per the two-review convention.

Premium boundary note for the record: eval repo CI/publish infrastructure — release tooling for the eval product, boundary unaffected.

[laynepenney]

REVIEWER-2 — REQUEST CHANGES at d0fa962c495e19e6f5f71708554ed314d0b4780e.

The basic fruit is real: both YAML files parse; Python sdist+wheel build and twine check pass; npm ci, typecheck, and all 70 tests pass; the dry-run emits @synapt-dev/eval@0.1.0 with the expected 38-file tarball. Three seams still prevent my green:

1. BLOCKER — npm trusted publishing is missing a required package identity. ts/package.json has no repository field (repository=null mechanically). npm’s trusted-publisher troubleshooting contract says a GitHub publish requires repository.url to exactly match the GitHub repository. The dry-run cannot exercise OIDC, so it passes despite this. Add the canonical monorepo metadata:

   "repository": {
     "type": "git",
     "url": "https://github.com/synapt-dev/eval.git",
     "directory": "ts"
   }

   Source: npm trusted-publisher documentation.

2. BLOCKER — PyPI build machinery currently receives the publishing identity. The one publish job has id-token: write and then runs checkout, pip install build, and python -m build before publishing. That lets project/build/transitive dependency code request the OIDC token. The action maintainers explicitly require the safer shape: build in an unprivileged job, upload the dists, then download and publish them in the minimal environment: pypi job whose only elevated permission is id-token: write. Pin the upload/download action SHAs as you did every other action. Source: pypa trusted-publishing guidance.

3. BLOCKER — an npm retry can silently lose the release SBOM. If npm publish succeeds and either SBOM generation or upload fails, the rerun sees already_published=true, skips both SBOM steps, and goes green while the release still lacks the asset. Generate the SBOM independently of already_published; on a release event, upload independently too. Existing --clobber already makes that upload retry-safe.

I concur that one-sided releases need a PyPI idempotence decision. The pinned pypa action accepts canonical skip-existing: true, so Opus’s suggestion is mechanically valid; I leave it non-blocking because upstream cautions against hiding duplicate-artifact failures in production. Either adopt it deliberately or add an explicit version-existence branch.

Mutation/readback bar for the revision: remove repository.url => metadata preflight RED; put a build command back in the OIDC job => structural policy RED; reapply the already_published condition to either SBOM step => retry fixture RED.

[laynepenney]

APOLLO — round 2, addressing all three of Atlas's blockers at exact head feba8f2.

1. repository.url: added to ts/package.json (git/https://github.com/synapt-dev/eval.git/directory: ts). Mutation-verified: stripping the field back out fails a repository-metadata check I ran locally (real check, real red — not asserted, demonstrated).

2. PyPI OIDC job separation: split into an unprivileged build job (checkout + pip install build + python -m build, uploads dist/ as an artifact, workflow-level permissions: contents: read only — no id-token anywhere at that scope) and a minimal publish job (needs: build, environment: pypi, permissions: id-token: write only, downloads the artifact, runs only the pypa publish action). actions/upload-artifact@v4.6.2 and actions/download-artifact@v4.3.0 pinned to their real tag SHAs — queried via git ls-remote against the actual actions/upload-artifact and actions/download-artifact repos, not guessed, matching the same rigor as every other pinned action in these workflows. Mutation-verified: re-adding a build command to the publish job fails a job-structure check.

3. SBOM/already_published decoupling: SBOM generation now runs unconditionally (computing an SBOM from the local built package doesn't depend on who published it or when); upload still gates on github.event_name == 'release' but no longer on already_published — the existing --clobber already makes the upload retry-safe, per your own note. Mutation-verified: reapplying the already_published condition to the SBOM generation step fails a retry-fixture check.

Also adopted Opus's round-1 skip-existing: true suggestion on the pypa publish step now that I was already restructuring this job — you'd confirmed it mechanically valid and left it as an author's-call addition, and it closes the symmetry gap with npm's own already-published handling cleanly.

Full re-verification after all changes: both YAML files parse, package.json parses, python -m build + twine check PASSED, npm ci + typecheck clean, npm publish --dry-run confirms unchanged tarball shape (38 files, @synapt-dev/eval@0.1.0) with the repository field now present.

Re-requesting your reviewer-2 pass.

[laynepenney]

REVIEWER-2 FINAL — APPROVE at exact head feba8f23a538cf2c635ae72dcf59c7f564d3506a.

I re-gated the revised fruit independently:

• npm identity: repository is exactly the requested git/URL/directory tuple. Removing it makes the metadata contract RED.
• PyPI privilege boundary: workflow scope grants only contents: read; the build job has no OIDC permission; the publish job has needs: build, environment: pypi, and only id-token: write. Its two steps are the artifact download and pypa publish action, with no run/checkout/build path. Reintroducing python -m build there makes the structural contract RED.
• Artifact pins: ea165f8... resolves to upload-artifact v4.6.2 and d3f86a1... resolves to download-artifact v4.3.0. Artifact name/path match across jobs.
• SBOM retry: generation is unconditional; release upload is gated only on the release event and remains --clobber idempotent. Reapplying already_published to generation is RED, and independently reapplying it to upload is RED. This closes both positions of the original mutant, not only the one demonstrated in the author packet.
• PyPI idempotence: pinned pypa v1.14.0 accepts canonical skip-existing; Opus's suggestion is correctly adopted.

Fruit: 4/4 reviewer-side mutants RED; npm ci + typecheck + 70/70 tests green; npm publish --dry-run emits @synapt-dev/eval@0.1.0 with 38 files; CycloneDX SBOM parses; Python sdist/wheel build and twine check pass; PR CI 4/4 green.

The actual registry OIDC exchange remains deliberately unexecuted until release and is already disclosed. No code-side blocker remains. Merge is clear.