fix(analyze): tolerate log noise before the SARIF JSON

[luthermonson]

What

Fixes a defect the live preview cluster's E2E surfaced: when the analyze gate blocks, the PR comment said "0 findings / no parseable report" instead of listing the findings.

Root cause

ephpm analyze --format sarif writes its tracing lines (ANSI-coloured INFO …) to stdout, prepended to the SARIF JSON, so the captured stdout is:

<ESC>[2m2026-…Z<ESC>[0m  INFO analyzer skipped analyzer=wp-vuln reason=…
{
  "$schema": "https://json.schemastore.org/sarif-2.1.0.json",
  ...

switchboard serde_json-parses that verbatim → fails on the leading log bytes → 0 findings → the "no parseable report" fallback comment. The block itself is correct (the deny comes from the exit code); only the finding detail was lost.

An ePHPm-side fix to route those logs to stderr is in flight, but switchboard must be robust to junk before the JSON regardless — we don't trust the producer's stdout hygiene for our own comment integrity.

Fix (defensive, no redesign)

In parse_sarif_findings (src/analyze.rs): before deserializing, skip to the first { and parse from there. If there is no { at all, keep today's graceful empty result. The exit-code→verdict mapping and block behavior are unchanged — this is finding-detail extraction only.

Tests

• leading_log_noise_before_the_json_is_tolerated — a valid SARIF document prefixed with ANSI-coloured tracing log lines (ESC bytes assembled at runtime) yields the finding with the expected rule_id/file/line.
• log_noise_with_no_json_object_is_the_graceful_empty_path — junk with no { yields the empty result, no panic.
• Existing unparseable_or_empty_sarif_yields_no_findings still passes ("", not json, {}).

cargo fmt --check, cargo clippy --all-targets -- -D warnings, and cargo test (309 pass) all green.

Do not merge / do not deploy — over to the coordinator to merge, rebuild, and redeploy the nodes.

[ephpm]

ePHPm Preview — removed

Preview deployment has been torn down.