send_message_stream silently discarded MessageRequest.channel_type,
sender_id, and is_group when calling the kernel — falling through to
the Persistent branch in the session resolver and collapsing every
chat (DM, group, stranger) onto the global per-agent session pointer.
The non-streaming sibling send_message correctly builds a SenderContext
via request_sender_context(&req); the streaming variant has done the
wrong thing since the streaming path landed. Because the WhatsApp
gateway defaults to forwardToLibreFangStreaming, the broken path is
hit on virtually all inbound WA traffic.

Live repro 2026-05-19: a family-group image was OCR'd into the owner
DM history at 16:16; an owner request for TTS voice notes generated
a reply that emitted into the group at 16:18 — both leaks are the
same single-session bug observed from opposite angles. After this
commit, /api/agents/<id>/message/stream resolves
SessionId::for_sender_scope(agent, channel, chat_id) and the two
chats land on separate session UUIDs.

Adaptation for custom branch layout: custom already exposes
`send_message_streaming_with_sender_context_routing_thinking_and_session`
in kernel/mod.rs (line 5539), so the call site in routes/agents.rs
switches to that variant when sender_context resolves, falling back
to the legacy routing-only path otherwise.

Mirrors upstream PR librefang#5288.

Two follow-ups on PR librefang#5288 (streaming session resolver):

1. Promote the precondition unit test: extract
   `build_streaming_kernel_args` from the streaming handler so the new
   `test_streaming_handler_threads_sender_context_to_kernel_args` test
   exercises the exact code path that hands sender_context / incognito
   / session_id_override to `send_message_streaming_with_incognito`.
   A future mutation that silently drops one of these fields on the
   way to the kernel call now breaks the test, not just a sibling
   helper. Full SSE-driven e2e (TestServer + kernel mock capturing
   args) was considered and rejected as too heavy for a linear
   data-flow assertion — tradeoff documented in the test docstring.

2. Add an ownership-choice comment near the trait/impl signature
   divergence at `kernel_api.rs:531` (trait takes
   `Option<SenderContext>` by value, impl forwards
   `Option<&SenderContext>` via `.as_ref()`). Explains why the two
   forms are intentional and warns future readers off "unifying" the
   signature without auditing callsites.

Rebase: no-op — branch already merged main (ff49320, aca1c9e)
overnight; CI green on the previous head.

Verification:
- cargo check -p librefang-api -p librefang-kernel --lib: ok
- cargo test -p librefang-api --lib test_streaming: 2 passed
- cargo clippy -p librefang-api -p librefang-kernel --lib -- -D warnings: clean
- cargo fmt: applied

…ibrefang#5288 streaming-resolver fix

Image 5659b0ce (lpk v1.0.5, built 2026-05-20T05:02Z) was deployed and
contains e21b9ad (streaming sender_context fix) — yet incident
2026-05-20 chat 120957 msg 355211 shows the DM image leak still
reaches the group session. Force a fresh rebuild from current custom
HEAD so we have a known-good image to bisect against the leak path.

…s-chat image leak

`SessionWriter::inject_attachment_blocks` took only `(agent_id, blocks)`
and wrote into `entry.session_id` — the agent registry's single
persistent session slot, NOT the per-chat session derived for the
current turn. For a chat agent with `session_mode = "persistent"`
whose group chat stays warm, any subsequent DM-inbound image landed
in the *group* session instead of the DM that should have received it.

Real production incident 2026-05-20:
- WhatsApp DM (chat 121043) at 08:43:13Z: owner sent a private
  Amazon-order screenshot ("metro laser, 27,98€") + caption "segna
  spesa in Shopping".
- WhatsApp group "Non perdiamoci 💻" (chat 120957) at 09:44:04Z
  (1h later): agent replied to a third party in the public group
  with those private order details verbatim.
- msgpack dump of the group session showed `[Image (image/jpeg)
  previously processed]` at the same second as the DM inbound —
  the DM image had been persisted into the group session's history.

PR librefang#5288 (streaming sender-context resolver) fixed an analogous gap
on the text-streaming path but deliberately did NOT touch the
attachment pre-inject step that runs BEFORE the streaming /
non-streaming handler proper — that step still used
`entry.session_id`, so even with librefang#5288 deployed the attachment
routing remained broken.

The fix:

- `SessionWriter::inject_attachment_blocks` trait signature now
  requires an explicit `session_id` parameter. The kernel impl writes
  into THAT session, never falls back to `entry.session_id`.
- `inject_attachments_into_session` in `crates/librefang-api/src/routes/agents.rs`
  takes `sender_context: Option<&SenderContext>` and `session_id_override:
  Option<SessionId>` and derives the same session id `send_message_*`
  would for this turn, using `SessionId::for_sender_scope(agent_id,
  channel, chat_id)` — byte-for-byte mirroring the existing text-path
  resolver.
- Both call sites (the streaming handler in `send_message_stream` and
  the non-streaming handler in `send_message`) now plumb sender_context
  + session_id_override through to the attachment inject step, so
  image / PDF / text content blocks land in the SAME session as the
  text part of the same request.
- The Web UI path in `ws.rs` resolves a fallback session id from the
  agent registry (web UI has no channel sender context) — labelled
  with a comment so a future audit doesn't mistake it for the bug.

Regression coverage:
`crates/librefang-kernel/tests/attachment_session_isolation_test.rs`
pins the trait contract — passing `(agent_id, X, blocks)` writes into
session `X`, never into `entry.session_id`; any future "fall back to
entry.session_id" reintroduction trips the assertion.

Out-of-scope sites with the same root-cause class (registry-default
session_id used as a session_id for chat-bound writes) — to be
fixed in follow-up commits on this same branch:
- `replace_tool_result_in_session` (`kernel/mod.rs` ~line 1535)
- `skill_workshop::find_last_turn` (`skill_workshop/mod.rs` ~line 527)

SessionId implements Copy; calling .clone() on Option<SessionId>
triggers clippy::clone_on_copy (-D warnings) and blocks the Quality
lane. Introduced by #5288 (thread sender context); fix is a trivial
drop of the .clone() call in the build_streaming_kernel_args test helper.

…cked by a hung phase (#5662)

* fix(daemon): bound graceful shutdown so daemon.lock release isn't blocked by a hung phase (#5477)

When the post-`with_graceful_shutdown` cleanup path stalls (channel
bridge waiting on an unresponsive sidecar subprocess, tmux socket
wedged, etc.), the process keeps holding `~/.librefang/daemon.lock`
indefinitely. launchd with `KeepAlive=true` then spawns a second
daemon that fails the lock acquire — the reporter's observed
"zombie + respawn" race.

Adds three bounds to `start_api_server`:

1. **Outer watchdog (30s)**: once axum returns, a background task arms
   `SHUTDOWN_HARD_DEADLINE`. If cleanup is not done in time it
   `std::process::abort()`s the process. flock(2) releases on any
   exit so launchd respawns immediately into a free lock instead of
   contending with a zombie. ERROR log includes `#5477` for ops.

2. **Channel bridge stop (5s)**: `bridge_manager.stop().await` is now
   wrapped in `tokio::time::timeout`. A hung sidecar drains
   best-effort but cannot stall the whole shutdown. WARN log on
   timeout.

3. **tmux session cleanup (5s)**: `tmux kill-session` over the socket
   can stall when tmux itself is wedged; same `tokio::time::timeout`
   wrap. WARN log on timeout.

Existing 5-second-per-task background-task timeout (the only bound
that pre-existed in this path) is left in place.

Trade-off: a hard `process::abort` skips Drop impls, so a sidecar's
`compose down` may not run if the watchdog fires. The outer
`observability_guard.take()`'s Drop already handles the SIGTERM /
panic case in the same way, so we're consistent. Net effect — losing
some best-effort cleanup is strictly less bad than holding the lock
against the next daemon respawn.

Closes #5477.

* fix(api): remove clone_on_copy lint on Copy SessionId in streaming test

SessionId implements Copy; calling .clone() on Option<SessionId>
triggers clippy::clone_on_copy (-D warnings) and blocks the Quality
lane. Introduced by #5288 (thread sender context); fix is a trivial
drop of the .clone() call in the build_streaming_kernel_args test helper.

…s-chat image leak

`SessionWriter::inject_attachment_blocks` took only `(agent_id, blocks)`
and wrote into `entry.session_id` — the agent registry's single
persistent session slot, NOT the per-chat session derived for the
current turn. For a chat agent with `session_mode = "persistent"`
whose group chat stays warm, any subsequent DM-inbound image landed
in the *group* session instead of the DM that should have received it.

Real production incident 2026-05-20:
- WhatsApp DM (chat 121043) at 08:43:13Z: owner sent a private
  Amazon-order screenshot ("metro laser, 27,98€") + caption "segna
  spesa in Shopping".
- WhatsApp group "Non perdiamoci 💻" (chat 120957) at 09:44:04Z
  (1h later): agent replied to a third party in the public group
  with those private order details verbatim.
- msgpack dump of the group session showed `[Image (image/jpeg)
  previously processed]` at the same second as the DM inbound —
  the DM image had been persisted into the group session's history.

PR librefang#5288 (streaming sender-context resolver) fixed an analogous gap
on the text-streaming path but deliberately did NOT touch the
attachment pre-inject step that runs BEFORE the streaming /
non-streaming handler proper — that step still used
`entry.session_id`, so even with librefang#5288 deployed the attachment
routing remained broken.

The fix:

- `SessionWriter::inject_attachment_blocks` trait signature now
  requires an explicit `session_id` parameter. The kernel impl writes
  into THAT session, never falls back to `entry.session_id`.
- `inject_attachments_into_session` in `crates/librefang-api/src/routes/agents.rs`
  takes `sender_context: Option<&SenderContext>` and `session_id_override:
  Option<SessionId>` and derives the same session id `send_message_*`
  would for this turn, using `SessionId::for_sender_scope(agent_id,
  channel, chat_id)` — byte-for-byte mirroring the existing text-path
  resolver.
- Both call sites (the streaming handler in `send_message_stream` and
  the non-streaming handler in `send_message`) now plumb sender_context
  + session_id_override through to the attachment inject step, so
  image / PDF / text content blocks land in the SAME session as the
  text part of the same request.
- The Web UI path in `ws.rs` resolves a fallback session id from the
  agent registry (web UI has no channel sender context) — labelled
  with a comment so a future audit doesn't mistake it for the bug.

Regression coverage:
`crates/librefang-kernel/tests/attachment_session_isolation_test.rs`
pins the trait contract — passing `(agent_id, X, blocks)` writes into
session `X`, never into `entry.session_id`; any future "fall back to
entry.session_id" reintroduction trips the assertion.

Out-of-scope sites with the same root-cause class (registry-default
session_id used as a session_id for chat-bound writes) — to be
fixed in follow-up commits on this same branch:
- `replace_tool_result_in_session` (`kernel/mod.rs` ~line 1535)
- `skill_workshop::find_last_turn` (`skill_workshop/mod.rs` ~line 527)

…s-chat image leak (#5334)

* fix(api): isolate attachment pre-inject per chat session — close cross-chat image leak

`SessionWriter::inject_attachment_blocks` took only `(agent_id, blocks)`
and wrote into `entry.session_id` — the agent registry's single
persistent session slot, NOT the per-chat session derived for the
current turn. For a chat agent with `session_mode = "persistent"`
whose group chat stays warm, any subsequent DM-inbound image landed
in the *group* session instead of the DM that should have received it.

Real production incident 2026-05-20:
- WhatsApp DM (chat 121043) at 08:43:13Z: owner sent a private
  Amazon-order screenshot ("metro laser, 27,98€") + caption "segna
  spesa in Shopping".
- WhatsApp group "Non perdiamoci 💻" (chat 120957) at 09:44:04Z
  (1h later): agent replied to a third party in the public group
  with those private order details verbatim.
- msgpack dump of the group session showed `[Image (image/jpeg)
  previously processed]` at the same second as the DM inbound —
  the DM image had been persisted into the group session's history.

PR #5288 (streaming sender-context resolver) fixed an analogous gap
on the text-streaming path but deliberately did NOT touch the
attachment pre-inject step that runs BEFORE the streaming /
non-streaming handler proper — that step still used
`entry.session_id`, so even with #5288 deployed the attachment
routing remained broken.

The fix:

- `SessionWriter::inject_attachment_blocks` trait signature now
  requires an explicit `session_id` parameter. The kernel impl writes
  into THAT session, never falls back to `entry.session_id`.
- `inject_attachments_into_session` in `crates/librefang-api/src/routes/agents.rs`
  takes `sender_context: Option<&SenderContext>` and `session_id_override:
  Option<SessionId>` and derives the same session id `send_message_*`
  would for this turn, using `SessionId::for_sender_scope(agent_id,
  channel, chat_id)` — byte-for-byte mirroring the existing text-path
  resolver.
- Both call sites (the streaming handler in `send_message_stream` and
  the non-streaming handler in `send_message`) now plumb sender_context
  + session_id_override through to the attachment inject step, so
  image / PDF / text content blocks land in the SAME session as the
  text part of the same request.
- The Web UI path in `ws.rs` resolves a fallback session id from the
  agent registry (web UI has no channel sender context) — labelled
  with a comment so a future audit doesn't mistake it for the bug.

Regression coverage:
`crates/librefang-kernel/tests/attachment_session_isolation_test.rs`
pins the trait contract — passing `(agent_id, X, blocks)` writes into
session `X`, never into `entry.session_id`; any future "fall back to
entry.session_id" reintroduction trips the assertion.

Out-of-scope sites with the same root-cause class (registry-default
session_id used as a session_id for chat-bound writes) — to be
fixed in follow-up commits on this same branch:
- `replace_tool_result_in_session` (`kernel/mod.rs` ~line 1535)
- `skill_workshop::find_last_turn` (`skill_workshop/mod.rs` ~line 527)

* fix(api): session ownership check + rebase for attachment isolation

Add defense-in-depth session ownership validation in
inject_attachment_blocks: verify the target session belongs to the
requesting agent before writing, mirroring kernel/messaging.rs.

Also: rename _agent_id to agent_id in resolve_attachment_session_id,
resolve merge conflict with build_streaming_kernel_args from main.

---------

Co-authored-by: Federico Liva <[email protected]>
Co-authored-by: Evan <[email protected]>