Fix terminal color queries for light and automatic themes

[honzasladek]

On macOS with a light system appearance and Okena's Auto theme, the desktop renders a light terminal but the daemon answers OSC color queries using the dark palette. Codex can consequently draw a dark composer behind the terminal's dark default text. Switching to Light in the GUI also leaves the daemon's palette stale because the GUI uses SetSettings, which previously only persisted the preference.

Report the local desktop's resolved system appearance to its daemon at startup, on appearance changes, and after reconnecting. The report is transient and preserves the Auto preference; explicit themes still take precedence. Refresh the terminal palette after successfully storing settings, including GUI theme changes. The daemon remains the sole terminal-query responder, and the desktop does not send appearance reports to user-managed remote connections.

Validation on macOS:

• cargo test -p okena-terminal color_ --lib: 2 passed, including exact OSC 10/11 replies for light and dark palettes.
• cargo test -p okena-daemon-core -p okena-app daemon_config::tests --lib: 4 passed; also compiles the desktop integration. Covers Auto light/dark transitions, explicit theme precedence, SetSettings palette updates, and failed persistence.
• Built the embedded web client with bun install --frozen-lockfile && bun run build.
• git diff --check passed. The standalone daemon dependency graph still excludes GPUI.

The daemon-only test command is blocked by an existing unrelated compile error in okena-files/src/history.rs: get_file_at_source references the GUI-gated file_viewer::FileSource without a matching feature gate. Tests above use the desktop's feature unification; this PR does not change those dependencies.

Manual GUI/Codex verification remains: select Auto on a light macOS desktop (or explicitly select Light), then launch a fresh Codex process and check composer contrast. Already-running applications may need restarting to query the updated colors.