[diegolopezrm]

What

When the first render --docker build runs past its 10 minute limit, the CLI now says the build timed out and that running the command again continues from the layers Docker already built. Before, it said "Check Docker is running", which sends you looking in the wrong place.

Why

On a small Docker VM (colima's default 2 CPUs) a first build can go past 10 minutes, and the old message made it look like Docker was down.

Related work

Fixes #5378.

How

The build error keeps the spawn error as its cause, and a small describeDockerBuildFailure picks the title and hint from it. Missing Docker and other build failures keep the messages they had. The 10 minute limit stays the same; it just has a name now so the message can quote it.

Test plan

Unit tests cover the timeout, missing Docker and any other build failure. I also built the CLI, set the limit to 3 seconds in the built file and forced an uncached amd64 build: the box now reads "Docker image build timed out" with the rerun hint. The rest of the CLI suite passes, except five whisper and file-watcher tests that fail the same way on main on this Mac.

• Unit tests added/updated
• Manual testing performed
• Documentation updated (if applicable)
• Comments follow CONTRIBUTING.md "Comments": they say why, not what, and a bug fix says what the code must do and how to reproduce the bug

[jrusso1020]

Approving at 9ca62fb7. Thanks!

• Timeout detection is right. On Node 22, an execFileSync timeout throws {code:"ETIMEDOUT", signal:"SIGTERM"} with stdio piped or inherited. isSpawnTimeout(error.cause) checks exactly that, and a build whose stderr merely contains the word "ETIMEDOUT" has no code, so it isn't mistaken for a timeout.
• Other failures keep the same regex, titles and hints as before.
• Tests: the new tests pass 3/3 and the render tests 98/98. Disabling the timeout branch fails the timeout test. Merges cleanly.

Two optional follow-ups:

• Removing { cause: error } in ensureDockerImage (render.ts:716) fails no test, and the fix depends on that one line. A test through ensureDockerImage with a mocked execFileSync would cover it.
• The hint could add that if one step alone takes more than 10 minutes, a rerun times out again.

— Rames

[diegolopezrm]

The Windows engine-cli failure looks unrelated: audioMixer.grouping.test.ts timed out at 5 s on the runner, and this PR only touches the CLI's Docker error message. Could someone re-run it?