fix: close spec-080 Command-handoff verification, rejection-visibility, and owner_key gaps

[bug-ops]

Summary

Three follow-ups to spec-080 (cross-thread store + Command-style dynamic task handoff, PR #6363), combined into one PR as independent, unblocked, same-epic gap-closing changes.

• Command-handoff outcomes skip SchedulerAction::Verify completeness check #6394 — TaskOutcome::Handoff now carries tool_trace and gets the same completeness-verification treatment Completed outcomes already had: handle_handoff_outcome emits SchedulerAction::CheckToolOutcome unconditionally and SchedulerAction::Verify when verify_completeness is enabled. This also fixes a spawn-path gap found during this PR's own review: a commanded_from-linked goto target kept running after its source was post-hoc corrected to Failed, since propagate_corrected_task_failure only walked depends_on-derived edges — closed via new dag::cancel_dangling_commanded_targets, scoped to Pending/Ready targets only.
• TaskNode.handoff_rejected not surfaced in TUI/CLI (Command-handoff rejection visibility) #6390 — TaskNode.handoff_rejected is now surfaced in /plan status (CLI) and the TUI plan view's task row, instead of only being logged.
• gateway/A2A store owner_key not threaded — cross-thread store isolation ready but not active #6389 — ChannelMessage gains an owner_key field, threaded per-turn through SessionState (mirrors the existing is_guest_context pattern) and read by /store and Command-handoff store I/O. Gateway and A2A dispatch paths now derive a real per-caller key (gateway:{sender}, a2a:{context_id}) instead of collapsing to the shared "local" sentinel. CLI/TUI/Telegram/Discord/Slack/JSON-CLI are unchanged.

Review notes

This PR went through a full two-round team-develop cycle: adversarial critique found 2 P2 findings and 1 P3 in the first pass; code review independently re-verified both P2s against the actual code before deciding severity, escalated the phantom-successor finding (#6394 spawn path) to merge-blocking after determining the correction chain that triggers it runs by default (not gated behind verify_completeness as initially assumed), and approved on re-review after the fix landed.

Known accepted, tracked-as-follow-up gaps (not fixed in this PR, documented in code comments and CHANGELOG.md):

• owner_key/is_guest_context can go stale across a fast-path slash-command dispatch that skips end_turn — pre-existing pattern, not a new hazard, no auth bypass (independently confirmed by security review).
• ACP sessions do not yet thread owner_key into the cross-thread store (only session-listing does).

Closes #6394
Closes #6390
Closes #6389

Test plan

• cargo clippy --profile ci --workspace --all-targets --features "desktop,ide,server,chat,pdf,scheduler,testing" -- -D warnings — clean
• cargo nextest run --config-file .github/nextest.toml --workspace --features "desktop,ide,server,chat,pdf,scheduler" --lib --bins — 14173 passed, 0 failed, 35 skipped
• cargo +nightly fmt --check — clean
• Rustdoc gate — clean
• New unit/regression tests for all three issues, including the phantom-successor fix (propagate_corrected_task_failure_cancels_pending_commanded_from_target, propagate_corrected_task_failure_leaves_running_commanded_from_target_untouched)
• CHANGELOG.md updated
• .local/testing/playbooks/orchestration.md and .local/testing/coverage-status.md updated (main repo) with live-testing scenarios for a future CI cycle
• Not yet live-tested against a real LLM session — structural/unit coverage only this cycle