Refactor loop bridge runtime and storage

[axeldelafosse]

Summary

• split the bridge implementation into focused constants, config, store, and runtime modules
• keep src/loop/bridge.ts as the MCP adapter while moving queue and delivery helpers behind shared runtime APIs
• update paired loop, tmux proxy, CLI/config wiring, and bridge tests to use the extracted modules directly

Verification

• bun run check
• bun test
• bun run build

Review

• peer review from Claude: no blocking findings

[gemini-code-assist]

Code Review

This pull request refactors the bridge implementation by splitting the monolithic src/loop/bridge.ts into several specialized modules: bridge-config.ts, bridge-constants.ts, bridge-runtime.ts, and bridge-store.ts. This change improves code organization and modularity across the bridge runtime, configuration, and storage layers. One piece of feedback was provided regarding the naming of stringifyToml, which currently uses JSON.stringify and could be misleading.

[gemini-code-assist]

The function stringifyToml uses JSON.stringify, which produces JSON output, not TOML. This naming is misleading. Additionally, please ensure that when communicating between agents in a paired tmux runtime, you use newline-delimited JSON on stdout for agent CLIs, as Content-Length framing can break registration/connection.

Suggested change

	const stringifyToml = (value: string): string => JSON.stringify(value);
	const stringifyJsonForToml = (value: string): string => JSON.stringify(value);

References

1. When communicating between agents in a paired tmux runtime, use newline-delimited JSON on stdout for agent CLIs, as Content-Length framing can break registration/connection.