Fail security workflows when OSV Scanner does not produce a valid result

[forkwright]

Finding

The reusable security workflow can report “No issues found” and succeed even when OSV Scanner never produces a result.

Evidence

• In forkwright/heurema, run https://github.com/forkwright/heurema/actions/runs/29861730470 and job 88739865767 completed successfully.
• The job log reports a missing osv-scanner.toml, OSV Scanner exit 127, and a reporter failure opening the result file.
• The same job then prints “No issues found”; the OSV job and overall workflow remain green.
• The shared workflow treats result presentation as proof of a successful scan. The canonical workflow delegates to it without proving that required inputs exist or that a valid result artifact was produced.
• Kanon #2293 and #2296 cover workflow/config convergence, but neither closes this false-green execution path.

Why this matters

A required security check currently proves that the reporting step ran, not that dependency scanning ran. Missing configuration, a broken scanner, or a malformed/missing result can therefore be indistinguishable from a clean repository.

Required mechanism

• Preflight the scanner configuration and supported lockfiles before invoking OSV Scanner.
• Require a successful scanner exit and a parseable result artifact with the expected schema before any clean verdict can be emitted.
• Preserve scanner/reporter failures as failing workflow outcomes; never convert absence of evidence into “No issues found.”
• Add negative fixtures for missing config, missing result, malformed result, and scanner crash/command-not-found.
• Propagate the corrected reusable workflow through the canonical fleet renderer and verify one intentionally broken consumer end to end.