feat: gate crucible-ci on multiplex's own unit tests

[k-rister]

Summary

• unittest.yaml previously ran standalone on every PR (pull_request trigger, its own unittest-complete job) but its result was never actually enforced: branch protection only requires crucible-ci-complete, not unittest-complete, so a failing test suite had zero effect on mergeability.
• Converts unittest.yaml to workflow_call/workflow_dispatch-only, keeping just the multiplex-unittests job (pytest + jsonschema venv, unchanged invocation).
• Wires it into crucible-ci.yaml with the same 3-part gating already merged in toolbox (#130) and rickshaw (#864), and just added to crucible itself: call-unittest shares call-real-core-release-crucible-ci's if: condition, is added to that job's needs: so a failing gate prevents the expensive integration run from starting, and is added directly to crucible-ci-complete's needs: too — a job skipped because a dependency failed reports skipped (not failure), and crucible-ci-complete's own check only looks for failure/cancelled, so without this direct dependency a failing gate would still produce a passing required check.
• Dropped .github/workflows/unittest.yaml from crucible-ci.yaml's docs-only skip-file list — it's the actual test payload now, not orchestration.
• No branch-protection change needed: verified live (gh api repos/perftool-incubator/multiplex/rulesets/3847755) that unittest-complete was never a required check to begin with, so this closes a real enforcement gap rather than needing a ruleset migration.

Test plan

• Ran all 60 tests (6 xfailed as expected) in a fresh venv with pytest/pytest-html/jsonschema — all pass
• Both workflow YAML files parse cleanly
• Confirm on this PR's own CI run: call-unittest passes before call-real-core-release-crucible-ci starts, call-faux-core-release-crucible-ci still correctly skips for non-docs changes

🤖 Generated with Claude Code

[k-rister]

PR Review: multiplex#110 — feat: gate crucible-ci on multiplex's own unit tests

Summary: Converts unittest.yaml from a standalone, independently-triggered workflow into a workflow_call-only reusable workflow gated by crucible-ci.yaml, mirroring the pattern already merged in toolbox (#130) and rickshaw (#864).
Changed files: 2
Review dimensions: Correctness, API & Contracts, Build & Deploy, Documentation, Style, Completeness

Documentation

• [README.md] CI badge will silently regress to "no status" once unittest.yaml loses its direct trigger — README.md currently has [![CI Actions Status](https://github.com/perftool-incubator/multiplex/workflows/unittest/badge.svg)], which today reflects real status (verified live: "unittest - passing"). This PR removes unittest.yaml's pull_request trigger, leaving only workflow_call/workflow_dispatch. GitHub does not track workflow_call-invoked sub-runs under the callee workflow's own badge/run history — confirmed empirically against toolbox, which underwent this exact same conversion in #130: gh run list --repo perftool-incubator/toolbox --workflow=unittest.yaml returns zero runs despite dozens of successful executions as a sub-job of crucible-ci.yaml, and toolbox's own workflows/unittest/badge.svg renders "no status". After this PR merges, multiplex's README badge will stop reflecting test health entirely rather than showing pass/fail. The fix toolbox uses is pointing the badge at workflows/crucible-ci/badge.svg instead (confirmed live: "crucible-ci - passing" for multiplex today, since that workflow keeps its direct pull_request trigger).

File Coverage

• .github/workflows/crucible-ci.yaml — No issues found (matches the toolbox/rickshaw pattern exactly; live CI on this PR confirms call-unittest passed before call-real-core-release-crucible-ci started)
• .github/workflows/unittest.yaml — No issues found directly; see Documentation finding for the downstream README consequence of its trigger change

Missing from diff:

• README.md — CI badge needs repointing from workflows/unittest to workflows/crucible-ci (see Documentation finding)

Limitations

Could not verify GitHub's badge behavior on multiplex itself post-merge (no time-travel), only inferred from toolbox's identical, already-merged conversion as a direct precedent. Did not re-verify the underlying multiplex-unittests test suite content, since it's unchanged by this PR and already passed on this PR's own CI run.

Verdict

Approve with comments — the workflow wiring is correct and CI-verified live; the only finding is a non-blocking README staleness issue the author can fix in this PR or a fast follow-up.

🤖 Generated with Claude Code

[k-rister]

Fixed in a7840c2.

Repointed the README CI badge from `workflows/unittest/badge.svg` to `workflows/crucible-ci/badge.svg`, matching the same fix toolbox applied for its identical conversion (#130). `unittest.yaml` no longer has a `pull_request` trigger, so its badge would otherwise silently regress to "no status" once this merges.

🤖 Generated with Claude Code

[atheurer]

Approved! This is a high-quality PR that correctly gates crucible-ci on local unittest runs:

1. Enforcement & Security: Directly chains call-unittest to crucible-ci-complete's needs, closing a critical branch-protection bypass where test failures could previously be skipped or ignored.
2. Resource Optimization: Correctly chains call-real-core-release-crucible-ci to depend on call-unittest so that expensive integration runs do not start if local unit tests fail.
3. Workflow Simplification: Cleans up redundant trigger filters and status aggregation jobs in unittest.yaml, adding safe timeout-minutes and secure permissions.
4. Badge Repointing: The README.md update (a7840c2) successfully prevents the CI badge from showing "no status" after the PR trigger removal.

Matches the ecosystem design established in toolbox#130 and rickshaw#864. Solid work!