fix(runner): skip the exit sentinel when picking a boot failure cause (DEV-3370)

[demtario]

Context

A Tier-2 boot that dies in cp -al was reported to Sentry with the title __RUNNER_EXIT__:1 (Sentry DEMOS-T), which hides the real error. failureDetail picks a cause in three tiers (an announcing line, a mentioning line, then the last line). The cp: cannot create hard link ... File exists lines match no marker, so the fallback took the last line, which is the wrapper's own __RUNNER_EXIT__:<code> sentinel written by the boot wrapper in workers/api/src/index.ts. This is a reporting misclassification only. The underlying "File exists" boot failure is not fixed here, because the cause could not be established from one event whose boot log is a 2500-byte tail.
The fix strips a trailing __RUNNER_EXIT__:\d+ from each log line when choosing a cause and drops the line if nothing remains. This also covers a sentinel glued onto an unterminated last line. The sentinel stays in the tail, so the exit code is still visible. execFailureDetail needs no change: its only caller is describeBuildFailure, which uses a direct sandbox exec result, not the boot wrapper.

Types of changes

• New example
• Update to an existing example
• README / documentation change
• Demo runner (runner/) change
• CI / tooling change

How was this verified?

Added tests in runner/pipeline/container-boot-failure.test.mjs for the DEMOS-T log, a sentinel-only log, a glued sentinel, and a non-zero sentinel after an announced cause. The sentinel-only, cp-collision and glued-sentinel tests fail against the old source and pass with the fix. The announced-cause test passes on the old source too and only guards against regression. The container-boot-failure and failure-log test files pass (38/0) and the runtime typecheck is clean. pnpm test in runner/ has one failure, theme-presets-version.test.mjs ("the pin tracks its own major's starter bucket"), which also fails on master because the authoring handsontable pin (18.1.1) trails bucket 18 (18.1.2); the fix is tracked in #424. An independent review of the diff was done and its findings are applied.

Checklist

• New/renamed example: added to runner/config/frameworks.json (see CONTRIBUTING.md); otherwise it won't appear on demos.handsontable.com
• New example: added a row to the tables in README.md
• Ran pnpm build (and pnpm dev) in the affected example/server-example locally

None of these apply: this changes runner runtime code only, and there is no example change.

Related issue(s):

1. DEV-3370

---

Note

Low Risk
Reporting-only change to how boot log lines are chosen for issue titles; no boot, install, or exec behavior changes.

Overview
Boot failures were sometimes titled in Sentry as __RUNNER_EXIT__:1 because failureDetail’s last-line fallback picked the API boot wrapper’s exit sentinel instead of real tool output (e.g. cp: … File exists lines that don’t match cause markers).

failureDetail now builds cause candidates by stripping a trailing __RUNNER_EXIT__:<code> from each line (including when glued to an unterminated last line) and dropping lines that become empty. The sentinel stays in tail so exit codes remain in context. execFailureDetail is unchanged.

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