fix(opencode): run CLI under a Linux pseudo-TTY so subprocess calls work

[kazutoshi-ishimori]

Summary

The opencode CLI requires a TTY. When beast mode invokes it via subprocess.run with piped stdout/stderr, it can return exit 0 with empty output and no generated files. The pipeline then treats this as a successful run that produced no code.

This PR wraps the opencode call on Linux with util-linux script so the CLI runs under a pseudo-TTY:

script -q -e -c "<cmd>" /dev/null

• -q suppresses script's start/done messages
• -c runs the requested command
• -e returns the child's exit status — without it script can return 0 even when the child command fails, which would re-mask an opencode failure as success (the very behaviour this wrapper exists to fix)

Why gate on Linux

The script -q -e -c ... /dev/null form is util-linux-specific. BSD/macOS script implementations are not compatible with this argument form, so an unconditional shutil.which("script") check could break non-Linux platforms rather than help them. The wrapper is therefore gated on sys.platform == "linux". On other platforms, and when script is missing, the bridge falls back to direct invocation — identical to current behaviour, with no regression.

Tests

Command construction is extracted into _build_opencode_command with unit tests covering:

• Linux wraps with script
• missing script falls back to direct invocation
• non-Linux platforms do not wrap
• child exit-status preservation uses -e
• shell metacharacters are quoted safely

tests/test_opencode_bridge.py passes (51 tests).

Notes

• Verified on Linux under WSL2 (util-linux 2.39.3): script -qc "exit 7" returns 0, while script -q -e -c "exit 7" correctly returns 7.
• I don't have a macOS/BSD environment to empirically test the fallback path; it's covered by mocked unit tests only.
• A fully cross-platform alternative would be Python's pty module, but that's a larger change — happy to follow up if preferred.