[Feature]: Authenticate clients on the agent IPC socket

### Problem / motivation

The agent owns the input hook and all HID I/O, and it runs with Accessibility and Input Monitoring grants. Any process in the same user session can connect to its IPC socket (`crates/openlogi-agent/src/server.rs:596-623`, endpoint `~/.config/openlogi/agent.sock` per `crates/openlogi-ipc/src/transport.rs`) and call RPCs such as `reload_config` or `action_ring_activate`. Since the config supports `RunShellCommand`, `RunAppleScript` and `TypeText` actions, an untrusted same-user process can drive the privileged agent without touching TCC itself.

To be clear about severity: the config file is user-writable anyway, so this is not a privilege boundary break. It is defense in depth. The Windows named pipe is already restricted to the creator and administrators by its default DACL, so the gap is mainly macOS and Linux.

### Proposed solution

Require proof of authorization from connecting clients. Options that come to mind: a per-session token written to a `0600` file next to the socket that clients must present, or peer credential checks where the platform supports them (`SO_PEERCRED` on Linux, `LOCAL_PEERCRED` on macOS). Happy to test whatever direction you prefer.

### Alternatives considered

None tried; current workaround is accepting that same-user processes can talk to the agent, same as most local daemons.

**Related areas:** Other

Start by reading the IPC server setup in crates/openlogi-agent/src/server.rs:596-623 and the socket transport in crates/openlogi-ipc/src/transport.rs, including the agent.sock endpoint. Determine the authorization approach for macOS and Linux clients, then verify that unauthorized same-session connections cannot invoke the agent RPCs while authorized clients still work.

Written by the indexing model from the issue text.