FE-1093: Harden orchestrator agent harness testing diagnostics

[kostandinang]

What

Adds profile-owned runner diagnostics for cook test execution.

Why

Runner/toolchain load failures, like Vitest being denied under confinement, should route as infra instead of product test failures.

Verification

• npx vitest run src/orchestrator/src/project-profile.test.ts src/orchestrator/src/test-runner.test.ts
• npm run verify reached the full test suite; unrelated graph type-contract tests timed out.

[kostandinang]

• FE-1093: Harden orchestrator agent harness testing diagnostics #269 👈 (View in Graphite)
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

[cursor]

PR Summary

Medium Risk
Changes how verify failures are routed (infra vs test vs absent); misclassification could skip real reds or send logic-fix agents at toolchain issues, but behavior is conservative and covered by new unit tests.

Overview
Adds profile-owned RunnerDiagnostics on each cook toolchain (runnerPackages, noTestsPatterns, runnerName) so failure classification is no longer hardcoded to Vitest wording.

classifyTestFailure now takes the active profile’s diagnostics: “no tests matched” uses per-runner regexes (e.g. Deno vs Vitest), and EPERM/EACCES on paths under /node_modules/{runnerPackage}/ is treated as infra (sandbox can’t load the runner). Permission errors on other packages (e.g. Playwright) still count as test failures.

isInfraSpawnError also treats spawn EACCES/EPERM as infra. ToolchainTestRunner passes toolchain.diagnostics when stamping failureKind.

^{Reviewed by Cursor Bugbot for commit be3c011. Bugbot is set up for automated code reviews on this repo. Configure here.}

[semgrep-code-hashintel]

Semgrep identified an issue in your code:
Ensure that the regex used to compare with user supplied input is safe from regular expression denial of service.

To resolve this comment:

🔧 No guidance has been designated for this issue. Fix according to your organization's approved methods.

💬 Ignore this finding

Reply with Semgrep commands to ignore this finding.

• /fp <comment> for false positive
• /ar <comment> for acceptable risk
• /other <comment> for all other reasons

Alternatively, triage in Semgrep AppSec Platform to ignore the finding created by regex_dos.

_{You can view more details about this finding in the Semgrep AppSec Platform.}