Build the debug artifacts the session probe drives, and act on a scanner report

[donislawdev]

Why CI is red, and what makes it green

CI has been failing on main for four pushes, since the commit that added crates/cli/tests/dry_run.rs. One test fails: the counter-probe that drives a real session so the --dry-run assertion is known to be capable of failing.

The cause is neither the test nor the product. cargo test never emits chrono_hook.dll - a test build compiles chrono-hook as a test harness, so the cdylib is not uplifted into target/debug, and the session refuses before it starts anything. On a developer machine that file is present from an earlier cargo build, so the probe passed by hand and failed on every clean runner from the day it was written.

Measured rather than reasoned: parking the file locally reproduced the runner's failure word for word, and cargo test --workspace did not put it back. cargo build --workspace did, in 3,4 s.

Three changes, not one:

1. CI builds before it tests. The cost is one cdylib link, because the dependencies were going to be compiled by the next step anyway.
2. The probe asks for the library first, so a checkout without a build gets the file name and the command to run, rather than the product's message about an incomplete installation - the right words for a user holding half a package, the wrong ones for whoever is running the tests. It asks is_file, exactly what core::hook_dll_in asks.
3. A new test reads the workflow. The precondition lives in another file and the local gate script builds too, so nothing else would notice the step leaving. That is how this was missed in the first place: the local gates reported all green while every push was red. The guard was watched failing with the step removed and with the step moved below the tests.

Rust tests go from 418 to 419, and the count is the point: a guard nobody has seen fail is decoration.

A matching gate was added to the local gate script so it can no longer be green while CI is red. That file is outside the repository, so it is not in this diff.

Not verified

Whether this test can pass on a hosted runner at all is unknown. The fix addresses the proven cause. This counter-probe would be the first real injection performed in CI, and runner policy could refuse it for a different reason. This run is how we find out.

Also in this branch

Four commits that were sitting unpushed, three of them acting on a static-analysis report.

• Script injection in two workflows. Six run: blocks interpolated ${{ }} into the body of the script. Expansion is textual and happens before the shell, so the quotes in the YAML protect nothing, and a git ref name may contain a quote, a backtick and a semicolon - in jobs holding id-token: write and attestations: write. Proven with a probe: with a hostile tag the old form executed the payload and the variable held only the leading characters, the new form printed the whole tag and ran nothing. Every interpolation is gone from those scripts, not only the ones a scanner calls dangerous, because "no ${{ }} inside a run: block" is something one grep can check.
• A cooldown on all three Dependabot ecosystems. Seven days, over the three applied by default, so a freshly published version ages before it is proposed. Security updates ignore the cooldown by design. Checked against the published schema rather than by eye, since a config error would stop Dependabot silently.
• Eleven findings from rules aimed at other kinds of program. Path traversal and command injection from a web-framework ruleset, an insecure WebSocket rule written for another language. All read in the code, none of them reaches this program, and each is suppressed per rule id with the reason beside it. Ten were watched appearing and then disappearing under the scanner. The eleventh does not reproduce under the open ruleset, so its marker is unproven and says so.
• A README correction from the previous session, saying that the release currently on the page is the unsigned one.

🤖 Generated with Claude Code