feat(evidence): publish relying-party clients with development builds

[jeremi]

Stacked on #649: the crates this builds are not on main yet, so the base is
feat/evidence-client-library.

evidence-dev.yml publishes dev builds of evidence, evidencectl, and
mint from protected-main source. It now also builds the two relying-party
client packages, which is the only way to try them before a tagged release
exists.

What the new clients job produces

Per platform (linux-amd64, linux-arm64, macos-arm64), one wheel and one
npm tarball:

Asset	Platform tag
registry_evidence_client-<version>.dev<run>-cp310-abi3-<plat>.whl	linux_x86_64, linux_aarch64, macosx_11_0_arm64
evidence-client-node-<tag>-<plat>.tgz	binding linux-x64-gnu, linux-arm64-gnu, darwin-arm64

Each is smoked from a fresh environment (a new venv, a new npm init project)
by installing the artifact and constructing a client: that is the failure a
prebuilt native artifact actually has. Nothing in the smokes touches the
network, and the placeholder token is a literal, not a credential.

Decisions worth reviewing

• One wheel per platform, no Python matrix. pyo3's abi3-py310 makes a
  single wheel cover CPython 3.10 and later. The roster names the cp310-abi3
  tag explicitly, so dropping abi3 fails publication rather than quietly
  shipping wheels no documented command names.
• --compatibility linux, not maturin's manylinux audit. The audit derives
  a glibc floor from the compiled extension's symbols, so its tag is not
  predictable from the source, and this workflow publishes a closed roster of
  exactly named assets. The cost is a glibc floor of the build runner's, which
  the release notes now state.
• Prerelease versions per ecosystem. 0.17.0.dev<run_id> (PEP 440, sorts
  below the real 0.17.0) and 0.17.0-dev.<run_id>, so a tester can read
  pip show or npm ls instead of a file name. The run attempt has no legal
  PEP 440 home except a local segment some installers reject, so it appears
  only in asset file names.
• The Node version is bumped before napi build, because the build
  regenerates index.js, which embeds the version for its own fallback check.
• The Rust SDK is not published here. A git dependency pinned to the source
  commit already works with no release; the notes say so.

Review notes (release provenance)

The closed asset roster gains exactly the six new names, so a missing or
misnamed client artifact fails publication instead of shipping a partial
toolset. SHA256SUMS covers them by construction. The new job holds
contents: read only and needs no registry credentials: nothing is published
to PyPI or npm.

Verification

• actionlint clean.
• The clients job's four run bodies were rendered out of the YAML itself
  (not paraphrased) and executed:
  • macos-arm64, natively: all four steps pass, producing exactly
    registry_evidence_client-0.17.0.dev4242-cp310-abi3-macosx_11_0_arm64.whl
    and evidence-client-node-v0.17.0-dev.4242.1-macos-arm64.tgz.
  • linux-arm64, in node:22.12.0-bookworm on a git archive copy: the
    wheel lands as ...-cp310-abi3-linux_aarch64.whl (the assumption macOS
    cannot check), and the tarball carries
    package/evidence-client.linux-arm64-gnu.node and installs.
• linux-amd64 was not executed. Its two names are verified statically
  instead: the napi-generated index.js loads
  ./evidence-client.linux-x64-gnu.node on linux/x64/glibc, so builder and
  loader share one platform string, and --compatibility linux tags a wheel
  linux_$(uname -m). If either is wrong, the roster fails the job rather than
  publishing something broken.
• publish's roster step, also rendered from the YAML, passes against a
  fabricated 19-asset set and refuses that set with one wheel removed.
• The container run first failed the tarball check on a tarball that was in
  fact correct: tar -tzf | grep -qx under pipefail reports tar's SIGPIPE
  141 when grep -q exits early. macOS had passed on buffering luck. The check
  now captures the listing instead of piping it.

The first real end-to-end run is post-merge: evidence-dev.yml only dispatches
from refs/heads/main with a successful CI push run for that exact SHA.

crates/registry-evidence-client-py/README.md said no CI path invokes
maturin, which this change makes false; it now names both consumers.