fix(test): gave CLI-spawning tests explicit timeouts

Four tests spawn the full CLI entry graph (or compile a standalone binary)
and declared no timeout, so they inherited Bun's 5s default. Spawning
`src/cli.ts` costs ~900ms warm on a fast machine and ~3.1s cold, so the
budget is spent almost entirely on transpile. When CI runs the native
bucket with OMP_TEST_CONCURRENCY=4, a cold spawn on a contended runner
crosses 5s and the test fails with `timed out after 5000ms` plus a
trailing `killed 1 dangling process` - the subprocess was still alive when
the timeout fired.

Reproduced locally by oversubscribing the box (48 concurrent runs of the
same chunk): 48/48 failed with the identical signature, while 4-way
concurrency - what CI actually configures - passed every time. Only the
subprocess tests starve; the pure-unit tests in the same files pass.

Timeouts are sized to the work, matching existing subprocess tests
(read-cli-mcp-resource 30_000, acp-stdout-hygiene 60_000): 30s for CLI
spawns, 60s for the `bun build --compile` case. After the change, 64
concurrent runs of all three files produce zero timeouts.

`profile-cli.test.ts` gets the timeout on both spawn tests. Only the first
was observed failing, because it warms the transpile cache for its
sibling - that ordering is incidental and would flake if it changed.

These are drift and wiring assertions, not latency assertions, so a
generous ceiling costs nothing on a healthy run.

packages/coding-agent/test/cli/completions.test.ts

@@ -224,5 +224,8 @@ describe("omp completions (integration / drift)", () => {
 		// Hidden/default commands must NOT surface as completable subcommands.
 		expect(stdout).not.toContain("_omp_cmd_launch");
 		expect(stdout).not.toContain("_omp_cmd___complete");
-	});
+		// Spawns the whole CLI entry graph, so the wall time is cold-transpile bound
+		// (~1s warm) rather than an assertion about latency. Bun's 5s default starves
+		// it when CI runs several test chunks in parallel on a shared runner.
+	}, 30_000);
 });