fix: harden linux sandbox reverse bridge startup

[jy-tan]

Summary

Fix Linux sandbox helper startup so strict sandboxing can reliably expose inbound service ports. This addresses a reverse-bridge failure that was previously masked by auto-mode fallback in downstream Tusk CLI E2E tests.

Changes

• Replace the inline Linux helper bootstrap with a more robust script builder that uses explicit bootstrap input/log files under /tmp/fence
• Remove the /dev/null-dependent background helper startup path that was breaking socat bridge launch inside the sandbox
• Wait for helper processes and reverse-bridge sockets before running the user command instead of relying on a fixed sleep
• Preserve cleanup and Landlock wrapper behavior while routing helper diagnostics into a dedicated bootstrap log
• Add a Linux integration regression test that starts a sandboxed HTTP server through the library path and verifies the host can reach it via an exposed port

[cubic-dev-ai]

2 issues found across 2 files

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="internal/sandbox/linux.go">

<violation number="1" location="internal/sandbox/linux.go:478">
P1: The `fence_wait_for_helpers` return value is not checked, so the user command runs even when helper processes fail to start. Add `|| exit 1` (or `set -e`) so the sandbox aborts instead of running with a broken bridge.</violation>
</file>

<file name="internal/sandbox/integration_linux_test.go">

<violation number="1" location="internal/sandbox/integration_linux_test.go:484">
P2: Closing the temporary listener before initializing the reverse bridge makes this regression test race on the exposed port, so it can fail or pass against an unrelated local service.</violation>
</file>

_{Reply with feedback, questions, or to request a fix. Tag @cubic-dev-ai to re-run a review.}