ci: install the wheels without dev dependencies and run one audit

[Marc-cn]

Summary

Follow-up to #573, as discussed there. Adds a CI job that installs darnit the way a user does and runs one audit.

Every existing job, including "Plugin discovery smoke", installs with uv sync. That uses uv.lock and the dev group, so it cannot see (a) a newly published release of a dependency that breaks a fresh install, or (b) a dependency darnit imports without declaring it.

• scripts/non-dev-install-smoke.sh: creates a clean virtual environment, installs the given wheels with pip (fresh resolve, no lockfile, no dev dependencies), audits a throwaway repository at level 1, and fails if the audit exits non-zero, prints a traceback or "not installed", or passes no control.
• ci.yml, new job non_dev_install_smoke: builds the five wheels and runs the script twice, once with darnit-core + darnit-baseline only and once with everything darnit-mcp pulls in. Python 3.12, to match the container image.

Where it lives. You asked release-smoke.yml or its own job. I put it in ci.yml because release-smoke.yml runs on workflow_run after a release is published, which is too late for this. The script takes a dist directory, so release-smoke.yml can call it too if you want the same check there.

Why two installs. darnit-reproducibility declares packaging. A full darnit-mcp install therefore had packaging even when core did not declare it, and only the minimal install shows that gap. This also corrects something I wrote in #573: the packaging half did not affect "any install from a built wheel", only installs without darnit-reproducibility (such as the quick install in from-source.md). The tree-sitter half affected all of them.

Type of Change

CI only. No package code changes.

• Bug fix (non-breaking change fixing an issue)
• New feature (non-breaking change adding functionality)
• Breaking change (fix or feature causing existing functionality to change)
• Documentation update
• Refactoring (no functional changes)

Testing

• Tests pass locally (uv run pytest tests/ -v) (not re-run: no package or test code changed)
• Added tests for new functionality (the job is the test)
• Linting passes (shellcheck clean on the script; ci.yml parses)

The script, run on RHEL 10.2 against wheels built from current main and from 190e85c (the commit before #573). "held" means tree-sitter-language-pack<1.6.3 forced through PIP_CONSTRAINT, to reproduce the cap-only state:

Wheels	Install	Result
main	minimal	OK
main	full	OK
pre-fix	minimal	FAIL (AuthorityViolation crash)
pre-fix	minimal, tree-sitter held	FAIL ("cel-python not installed")
pre-fix	full	FAIL (AuthorityViolation crash)
pre-fix	full, tree-sitter held	OK (correct: packaging came through reproducibility)

Not verified locally: uv build --wheel --package darnit-mcp under the pinned uv 0.5.0 (I have 0.13; the existing Build job only builds core and baseline). CI on this PR is the test of that.

AI assistance

• No AI assistance was used
• AI assistance was used

Claude Fable 5.1 wrote the script and drafted this description. I ran every case in the table myself. The commit carries an Assisted-by: Claude:claude-fable-5-1 trailer.

Additional Notes

• The job depends on what is on PyPI that day. It will go red when an upstream release breaks a fresh install, on PRs that did nothing wrong. That is the point of it, but it is a change in how CI behaves.
• It checks "at least one control passes", using the two expression-based controls that pass on a near-empty repository. If those controls change, the assertion needs to follow.