Separate Pi retry policy from lifecycle process coverage

[ymichael]

What was wrong

The Pi lifecycle test coupled two separate contracts. To prove that a failed construction leaves no child, it requested a permanently mismatched model. Production correctly treats an initial mismatch as a transient auth race and retries eight times, so this single lifecycle assertion launched nine real Node children in series and imported the real Pi extension nine times. The test asserted only that more than one child spawned and that all children exited; it did not need nine real processes to prove cleanup. Under packages-shard contention, those avoidable serial launches crossed the harness's unchanged 60-second response deadline and produced no response to thread/start in the failed packages job on PR #2349.

What changed

The retry policy and real-process lifecycle coverage are now separate:

• runPiTransientAuthConstruction contains the unchanged production policy and accepts injected construction, discard, closed-state, and wait operations. A zero-process test deterministically proves one initial attempt plus eight retries, eight failed-attempt discards, and propagation of the ninth error.
• The existing real-process transient-mismatch test still proves that a mismatched child is killed, a replacement child succeeds, and no construction-time session error leaks.
• The failed-construction lifecycle test now uses a fake-Pi fault that exits before its first response. It launches one real child and still verifies the bridge error, exact spawn count, observed process exit, and no child left behind.
• The scratch-file lifecycle case uses the same one-process construction failure and verifies its tool/prompt files disappear after the child exits.

The earlier timeout-only changes were reverted: the shared request deadline remains 60 seconds, and the existing lifecycle wrappers remain 90 and 60 seconds. Production retry count, delay, child detachment, and error behavior are unchanged. This does not alter the host-daemon wire protocol, so HOST_DAEMON_PROTOCOL_VERSION is unchanged.

How you verified

Before edits, the parent and worker independently confirmed that HEAD, origin/main, and git merge-base HEAD origin/main all equaled 21cb6b68b8fdffe2cd576f11c8af500f98d22c11, with a clean worktree. Exact GitHub issue/PR and bb thread searches found no overlapping lifecycle fix; PRs #2337 and #2342 cover different provider-pi signatures.

The original coupled test reproduced the exact CI error under 256 CPU competitors at 61.288 seconds: Error: no response to thread/start. With the structural split and the original clocks restored, the identical stress command passed with 150 milliseconds of lifecycle test time (7.73 seconds total including imports). The deterministic nine-attempt policy test completes in 1–2 milliseconds.

• Focused retry-policy and failed-construction coverage — 3 passed, 6 skipped
• pnpm exec turbo run test --filter=bb-plugin-provider-pi --force — 18 files, 105 tests passed
• pnpm exec turbo run typecheck --filter=bb-plugin-provider-pi --force — 4 Turbo tasks passed
• pnpm exec turbo run build --filter=@bb/server --force — 4 Turbo tasks passed
• pnpm exec oxfmt plugins/provider-pi/src/bridge/rpc-session.retry.test.ts --check — passed
• git diff origin/main --check — passed

AGENT GENERATED: by GPT-5.6-Sol