A failed check says only that it exited 1; the failing test is buried in a 240-second log #315

Pushed successfully.

A failed check's summary now names what actually failed, instead of just its exit code.

• New pure function summariseCheckFailure (src/checks/summary.ts) reads the check step's own output tail: when it's bun test's shape it produces check failed: 2 of 3 tests — "first failing test"; otherwise it falls back to the last non-empty line of output, and only to the bare exit code (check exited with code 1) when there was genuinely no output to read from.
• checks/service.ts now excludes runStep's own command echo from what it summarises, and threads checkDetail (already computed via parseBunTestFailure) alongside the new summary.
• The crew's park comment for a red check (crew/dispatch.ts) now names the failing test too, e.g. the check failed ("renders the broken widget") and the decider saw no point in another try — plumbed through a new failingTest field on CheckJudgement.
• Tests: the real timeout example from the issue, the fallback cases (typecheck-style output, no output at all), truncation of an overlong name, and an end-to-end check run and park-comment assertion.

Left out: I didn't touch how a deploy's (as opposed to a check's) failure is summarised — that's issue #270's territory and already has its own fix (process.ts's failureReason, from #312). bun run check (the exact sharded command in forge.json) is green; a full unsharded bun test still shows the pre-existing cross-file pollution failures in unrelated areas (web/apps/origins/look) that #310 was chasing — none of those files were touched here.

Closes #278