security: Add authentication to TCP IPC and sanitize log inputs

[wilcorrea]

Summary

CodeRabbit identified two security concerns in the TCP IPC implementation:

1. Unauthenticated TCP Listener (Major - lib.rs:15)

The TCP listener on 127.0.0.1:7474 has no authentication or authorization. Unlike the Unix socket (gated behind #[cfg(unix)] with 0o600 permissions), any local process can connect and issue commands like open (to open arbitrary files) or show (to manipulate window focus).

On multi-user systems or shared hosts, this is a local attack surface.

Recommendations:

• Add token-based authentication (random token written to a file with restrictive permissions, client must present it)
• Or restrict TCP IPC behind a feature flag/cfg gate so it's opt-in
• Consider #[cfg(feature = "tcp-ipc")] on the module declaration with corresponding Cargo.toml feature

2. Log Injection via Unsanitized TCP Input (Minor - tcp_ipc.rs:71,75,94)

The code logs raw, attacker-controlled TCP input (line and cmd.command) which can contain newlines and inject fake log entries. While eprintln! is less exploitable than structured logging frameworks, newlines could forge log entries.

Additionally, serde_json::to_string(&response).unwrap_or_default() sends an empty line on serialization failure, which could confuse clients expecting valid JSON.

Recommendations:

• Sanitize/escape logged values (replace newlines, truncate length)
• Replace .unwrap_or_default() with a hardcoded error JSON string on serialization failure

References

• PR fix(tauri): resolve relative paths and prepare for IPC merge #12 CodeRabbit review comments
• Files: apps/tauri/src-tauri/src/lib.rs, apps/tauri/src-tauri/src/tcp_ipc.rs