… /mcp bridge (#6117)

An agent's `channel_send` could dispatch a message to a different recipient than the current turn's inbound peer on the same channel, with no validation — a cross-chat confidentiality leak observed live (audio voice notes delivered to a stranger's WhatsApp chat, 2026-05-19).

The leak vector is the subprocess-driver `/mcp` bridge: `network.rs::mcp_http` hardcoded sender_id / channel / chat_id to `None`, so `tool_channel_send` had no peer scope to validate against. A guard alone could not fire — the prerequisite peer-scope plumbing was absent on `main`.

This lands the full peer-scope propagation chain and the guard:

- `CompletionRequest` gains `sender_user_id` / `sender_channel` / `sender_chat_id`, populated from the turn's existing manifest-metadata bindings in the agent loop (streaming + non-streaming). Out-of-band callers (cron, triggers, compaction, routing probes) leave them `None`.
- The `claude-code` driver forwards them on the bridge connection as `X-LibreFang-Current-Peer-Jid` / `-Channel` / `-Chat-Id`, mirroring the existing `X-LibreFang-Agent-Id` pattern.
- `mcp_http` reads those headers back into `ToolExecContext`.
- `tool_channel_send` rejects an explicitly-targeted recipient that does not match the current conversation on the same channel. The comparison key is the conversation id (`sender_chat_id`, falling back to `sender_id` for DMs) so legitimate group replies pass. A different-channel dispatch stays allowed; an auto-filled recipient (reply to the inbound peer) is never scrutinised. Out-of-band callers with no peer scope run unguarded, preserving existing behaviour.

The new `CompletionRequest` fields default via the struct's existing `Default` derive, so the ~35 construction sites that do not carry peer scope use `..Default::default()` rather than each spelling out three `None`s.

Tests:
- `tool_runner::tests` — guard unit tests: same-channel mismatch DENIED, same-channel match passes, group reply to chat_id passes, cross-channel passes, out-of-band (no peer scope) passes.
- `claude_code` — `write_mcp_config` emits / omits the peer headers.
- `api_integration_test` — end-to-end `/mcp` `tools/call` for `channel_send` proving the headers reach the guard (blocked with headers, unguarded without).

Verification: `cargo check --workspace --lib`; `cargo clippy` (zero warnings) on the changed crates; scoped `cargo test` for librefang-runtime / llm-drivers / api / kernel.

…pient match + empty chat_id fallback (#6117)

Self-review hardening of the #6117 guard:

- Compare the explicit recipient case-SENSITIVELY. `send_channel_*` lookups are case-sensitive (#6078), so the earlier `eq_ignore_ascii_case` match would let `recipient = "OWNER-JID"` pass the guard while the send routed to a distinct case-sensitive chat — a narrow bypass. The channel match stays case-insensitive so the guard still fires when the model varies the channel casing.
- Filter an empty `sender_chat_id` before the `sender_id` DM fallback. The in-process path stamps the raw metadata value (the `/mcp` bridge already drops empty headers), so `Some("")` previously masked the fallback and silently disabled the guard.

Adds regression tests for both: a case-variant recipient is blocked, and an empty chat_id still enforces via the sender_id fallback.