ci(hostlock): run the lock's conformance suite, which nothing ran

[justinchuby]

Nothing ran the conformance suite

scripts/hostlock_test.sh is 252 assertions covering mutual exclusion, atomic publish, stale-holder reaping, fail-closed admission and the CPU-efficiency verdict of the advisory benchmark-host lock (#1803, #1806). No CI job ran it. It ran by hand, by me, on the box it locks — which is the same assigned, never executed shape the suite exists to prevent, one level up. A suite nobody runs is green because it is stale, not because the tool is correct.

It has earned the job. Three of the defects it caught were introduced by the fix for the previous one:

• an acquire that mkdired and then wrote its metadata handed the host to three simultaneous winners — a competitor reading in the window sees a lock with no anchor pid and reaps it as stale;
• the reaper's own mutex could be orphaned by a SIGKILL between mkdir and rmdir, after which no stale lock could ever be reaped again;
• reaper_release compared only $$, so on a box cycling ~1.5M pids in four days it could delete a live successor's guard.

Scope and cost, both deliberate

Path-filtered to scripts/hostlock*.sh and this workflow file, on PRs and pushes to main. The suite spends about ten core-seconds on real load — six spinners for the occupancy reading, three ~1.5 s single-cpu cells for the efficiency verdict — which is cheap but not free, and irrelevant to a PR that does not touch the lock.

Deliberately not a required check. The required set is Fast (Linux x86_64) and Rust quality; putting a shell job on every PR's critical path buys nothing for the PRs that never touch these two files.

The timeout is measured, not guessed

Under taskset -c 30,31 — two cores, the shape of a GitHub-hosted runner:

passed=252 failed=0
WALL_SECONDS=210.26  CPU_PCT=53%

210 s wall at 53% of a single core, i.e. the suite is mostly bounded waits rather than work. timeout-minutes: 20 is ~5× that — room for a slower runner, and far short of the six-hour default a genuinely hung wait would otherwise occupy.

That two-core run is also the evidence that this is safe on shared CI infrastructure at all: under #1802 every cell that needs to know what a run achieved measures the host and derives its threshold, instead of asserting a number only an idle box can produce.

Linux-only, matching the tool — hostlock.sh reads /proc/<pid>/stat for pid start times, relies on mv -T for its atomic publish, and uses stat -c; its PORTABILITY block says so.

Validation

• Workflow YAML parses; both steps verified locally (shellcheck clean, suite 252/252 green on the current branch and 252/252 under the two-core constraint).
• No crate code. One new file.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 80.34%. Comparing base (22083b0) to head (dcbef49).
⚠️ Report is 9 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1912      +/-   ##
==========================================
- Coverage   80.37%   80.34%   -0.03%     
==========================================
  Files         401      415      +14     
  Lines      195530   204600    +9070     
  Branches   195530   204600    +9070     
==========================================
+ Hits       157150   164385    +7235     
- Misses      32992    34638    +1646     
- Partials     5388     5577     +189     

Flag	Coverage Δ
cli-ort-linux	72.51% <ø> (?)
cli-ort-windows	72.01% <ø> (?)
mlas	85.20% <ø> (?)
offline	80.47% <ø> (+0.10%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.
see 33 files with indirect coverage changes

🚀 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.