Unit test startup_failure_preserves_its_cause_without_completion_reporting runs a real installed opencode #652

This was generated by AI during triage.

Agent Brief

Category: bug
Summary: The unit test startup_failure_preserves_its_cause_without_completion_reporting runs a real installed opencode when one is on PATH

Current behavior:
To make spawning the selected Harness fail, the test leaves a fake opencode in the fixture's bin/ with mode 0644. The fixture's command puts that bin/ ahead of the developer's real PATH. When a PATH entry isn't executable, execvp doesn't stop: it remembers EACCES and keeps searching. On a host with OpenCode installed (for example ~/.opencode/bin/opencode), the test therefore starts a real OpenCode session with the fixture's implement prompt. On the thirdshift host that run took 22m 51s, then failed:

left:  "opencode exited 1: provider.internal: Provider request failed with HTTP 502"
right: "could not run opencode"

The test's comment says "This never falls through to a real installed Harness", which isn't true. CI passes only because CI has no opencode installed.

Desired behavior:
The test can never reach a Harness outside the fixture, whatever the developer has installed. A failed spawn should still produce the same error: could not run opencode, with an std::io::Error of kind PermissionDenied. No completion reporting, and no calls file.

Key interfaces:

• The session-execution test Fixture and the PATH it builds for the child test process: the fixture's bin/ is joined onto the inherited PATH.
• execute_session in fixture mode: the assertions on the error text and its PermissionDenied kind.

Acceptance criteria:

• With an executable opencode that records its invocation placed later on PATH (simulating a real install), the test passes quickly, and that opencode never runs. Check this once by hand, or as a test.
• The test still asserts could not run opencode with ErrorKind::PermissionDenied, plus no completion reporting and no calls file.
• The test's comment about not falling through to an installed Harness is accurate.
• Other fixture tests that rely on the inherited PATH for tools like bash, git or sleep keep passing.
• cargo test, cargo clippy --all-targets -- -D warnings and cargo fmt --check pass.

Out of scope:

• Changing how production code resolves Harness binaries or reports spawn failures.
• Auditing other tests for PATH leaks, unless one fails the same way on a host with real Harnesses installed. If any do, list them in the PR.