fix(multiscan): record run warnings in the campaign ledger

[ppcvote]

Fixes #248.

runMultiscan called security.run() with no onWarning observer, so every warning the scan raised was discarded. A repository whose target drifted mid-run still completes, so it landed in results.jsonl as status: "completed" with nothing in the campaign output recording that the results describe a tree that moved.

The receipt now carries a warnings array when the scan raised any:

{"id":"drifted","status":"completed","attempt":1,"outputDir":"...",
 "warnings":[{"message":"Scan target changed during the run.","kind":"target_changed"}]}

kind comes from ScanWarningDetails, so a consumer can single out drift without matching on message text — the same distinction the CLI already makes at its own onWarning.

Three decisions worth review

Redaction. Warnings go through redactedErrorMessage, the redaction the failure path already applies. The ledger is a file on disk and a warning can quote a remote or a token. The CLI uses sanitizeDiagnosticValue for this, but that is private to cli.ts; redactedErrorMessage is the equivalent already imported into multiscan.ts. Happy to export the CLI one instead if you would rather have a single sanitizer.

Per attempt. The array is declared beside failure and cost inside the retry loop, so a second attempt does not inherit the first attempt's warnings.

status is untouched. The scan completed; promoting a warning to a failure would be a louder change than the issue asks for and would break resume, since completed receipts are what let a rerun skip finished repositories. The key is omitted entirely when nothing was raised, so a quiet run produces byte-identical output to today.

Verification

Windows 10, bun 1.3.11, bun test tests-ts/multiscan.test.ts:

	with fix	without fix
records run warnings in the receipt	pass	fail
redacts credential-shaped values	pass	fail
omits warnings when none raised	pass	pass (control)
totals	16 pass, 1 fail	14 pass, 3 fail

The two failing-without-the-fix tests are the ones that matter; the third is a control that passes either way and guards against warnings appearing on a quiet run.

The single unrelated failure in both columns is rejects output-directory symlinks, which needs symlink privileges this host does not grant. It fails identically on unmodified main, so it is not residue from this change.

Related

This is the multiscan half of the same shape as #251 and #195: the tool knew something and the knowledge did not reach the artifact a consumer reads. Those are about the single-scan --json and SARIF surfaces; this one is the ledger. I have not touched either of those paths — #251 already has someone working on it.

[ppcvote]

Rebuilt against main, which had moved into this area and conflicted. Worth spelling out what changed, because the overlap is real but partial.

main now derives a warning from result.coverage.completeness, adds a completed_with_incomplete_coverage status and an incomplete tally. That covers the coverage case.

It does not cover what this PR is about. security.run() still receives no onWarning observer, so warnings the scan itself raises are still discarded. Coverage is computed locally from the returned result and never went through the observer path, so nothing about that change reaches the drift case in #248.

I kept the two signals separate rather than folding mine into main's warning, because their semantics differ in a way that would produce a wrong status:

• warning is coverage-derived, and its presence flips status to completed_with_incomplete_coverage.
• A repository whose target drifted mid-run has complete coverage. The scan reviewed everything it set out to review; the tree moved underneath it. Routing a drift warning into warning would report incomplete coverage for a run whose coverage was fine, and move it out of the completed tally.

So the observer-sourced entries land in scanWarnings, renamed from warnings to remove the collision. The names now say which layer raised it: the campaign derives warning, the scan raises scanWarnings.

scanPrompt / postScanPrompt from main are kept as-is; onWarning is added alongside them.

38 pass. The one failure is rejects output-directory symlinks, which needs symlink privileges this host does not grant and fails identically on unmodified main.

Happy to merge the two into a single field if you would rather have one, but it would need the status coupling loosened first, and that felt like a larger decision than this PR should make on its own.

[ppcvote]

Closing in favour of #255, which was open before this and covers the same ground.

I did not check for PRs already linked to the issue before opening this, which I should have. Apologies for the extra review load.