fix(core,acp): reset owner_key/is_guest_context staleness, thread ACP identity into cross-thread store

[bug-ops]

Summary

Two follow-ups from the cross-thread store owner_key work (spec-080, #6389 / PR #6416):

• session.owner_key/is_guest_context were set only in the LoopEvent::Message arm of the agent loop and reset only at Agent::end_turn. A fast-path slash-command dispatch that exits the loop iteration via DispatchFlow::Continue/Break before reaching end_turn could leave a stale value in place for the next LoopEvent (a scheduled task, autonomous tick, or a different sender's fast-path message). Both scalars are now reset unconditionally at the top of every Agent::run loop iteration, closing the gap uniformly across CLI/TUI/Telegram/gateway/A2A/ACP. end_turn's existing reset is kept as defense-in-depth.
• ACP dispatch never threaded its already-authenticated per-connection identity into the cross-thread store, collapsing every ACP session to the shared "local" bucket like the single-user CLI/TUI/Telegram paths, despite ACP having the strongest per-caller identity of any dispatch path. All three ChannelMessage construction sites in the ACP agent (do_prompt, /clear, /review) now carry that identity as owner_key.

Review notes

• impl-critic verified the reset placement is provably correct (nothing reads session.owner_key/is_guest_context between the reset and the point where they're set for the current iteration) and traced all ACP entry points to confirm the three ChannelMessage sites cover every path that reaches the cross-thread store.
• A related, narrower gap was found and confirmed out of scope: QueuedMessage has no owner_key/is_guest_context fields, so a ChannelMessage queued mid-turn silently loses its owner_key at drain_channel. Confirmed unreachable today (every channel that can carry a real owner_key routes through recv(), not try_recv()) and fail-safe in direction (falls back to the shared default bucket, never misattributes to another tenant). Worth a follow-up issue, not a blocker here.
• Reviewer independently ran the full CI-matching check suite (fmt, clippy --profile ci, nextest, rustdoc gate) after rebase — all green.

Test plan

• New regression test proving the fast-path staleness bug (verified load-bearing by reverting the fix and confirming the test fails)
• Two-turn Agent integration test asserting owner_key set/reset through a real turn
• scheduler_loop.rs test proving persist_handoff_update/append_shared_state_block are load-bearing on owner_key
• ACP owner_key-threading tests for /clear and /review
• cargo +nightly fmt --check
• cargo clippy --profile ci --workspace --all-targets --features "desktop,ide,server,chat,pdf,scheduler,testing" -- -D warnings
• cargo nextest run --workspace --features "desktop,ide,server,chat,pdf,scheduler" --lib --bins (14222 passed)
• rustdoc gate (RUSTFLAGS=-D warnings, --deny rustdoc::broken_intra_doc_links)

Closes #6418
Closes #6419