Build minimal Code Bridge service skeleton #46

Current Status

State: Proposed second implementation stage for #36, blocked on #45. This slice should prove the service/daemon mechanics before adding JS app clients, screenshots, or product adapters.

Acceptance Criteria

• Service binds loopback-only by default or uses a stdio/MCP-safe transport with equivalent local trust guarantees.
• Startup writes or exposes a bounded local connection descriptor with protocol version and auth material; owner-only permissions are verified where applicable.
• Missing or invalid auth is rejected before payload deserialization where practical.
• Service exposes status with protocol version, connected producer/subscriber counts, uptime, and last event time.
• Heartbeat and stale-client timeout behavior is covered.
• Payload-size rejection and clean shutdown are covered by tests.
• No product names, Launchplane semantics, Discord semantics, or app-server protocol changes are included in this slice.

Target Surface

Likely new crate under codex-rs/, such as code-bridge-service or codex-code-bridge, depending on crate naming conventions selected in #45. Avoid codex-core.

Validation Gate

Targeted Rust tests for the new service crate. If CLI commands are added, run the relevant CLI tests too. If dependencies change, update Bazel locks per repo guidance.

Risks

Local daemons invite stale PID/state files and accidental non-local exposure. Treat auth, bind address, stale descriptor cleanup, and payload bounds as first-class acceptance, not follow-up polish.

Finish Line

A local Code Bridge service starts safely, advertises status, enforces auth and payload limits, and passes loopback integration tests without app-server or product-adapter coupling.