fix(mcp): state the process boundary in mcp connect and mcp validate

[SparkofSpike]

Summary

codewhale mcp connect prints Connected to all configured MCP servers.
and codewhale mcp validate prints MCP config is valid. All enabled servers connected. — on their own, both read as if the running TUI/exec
session had now picked up those servers' tools. It has not: per
docs/MCP.md § Connection Lifecycle, these commands inspect their own
process's pool and never attach transports to a running session.

Issue #6828 hit exactly this confusion: the reporter connected successfully,
saw the green lines, and still had zero mcp_* tools in-session. The
in-session discovery path that report asked for is already on main
(verified end-to-end on Windows from the reporting host; evidence posted in
the issue) — this change closes the report's remaining CLI complaint.

Changes

• crates/tui/src/lib.rs
  • After both mcp connect success lines (single server / all servers) and
    the mcp validate success line, print a shared two-line note: the
    command ran in its own process and does not attach to a running TUI or
    exec session; and the supported in-session paths (search the server name
    or an mcp_<server>_ tool name, or call one of the server's tools
    directly). The note is printed only on the full-success paths — OAuth
    and partial-failure paths stay silent, as they should.
  • mcp connect --help now ends with "(does not attach to a running
    session)".
  • mcp tools / mcp list are unchanged: their output is data, and the
    note belongs on the command that claims a connection.
• Unit test mcp_own_process_note_states_the_session_boundary_and_recovery
  pins the note's two required elements (process boundary + in-session
  discovery pointer).

Pre-submission review ran in the author's fork (SparkofSpike#7)
across three independent channels: one approve, one adversarial pass with no
blocking findings (both flagged the same low-severity suggestion, judged
non-blocking and recorded on that PR), and one independent Codex/gpt pass
with no findings.

Type of Change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation update
• Refactoring (no functional changes)
• Tests

Testing

• cargo build --release -p codewhale-cli — clean (exit 0, Windows x64)
• cargo fmt -p codewhale-tui -- --check — clean
• Live check on the rebuilt binary (0.10.1 dev, isolated CODEWHALE_HOME):
  mcp connect <server>, mcp connect, and mcp validate all print the
  note; mcp connect --help shows the new line
• cargo test --release -p codewhale-tui --lib mcp_own_process_note —
  running locally; result posted as a comment
• cargo clippy / full workspace suite — deferred to CI

Checklist

• Updated docs or comments as needed (the note points at docs/MCP.md,
  which already stated this contract)
• Added or updated tests where relevant
• Verified TUI behavior manually if UI changes — n/a (CLI surface)

Related Issues

Refs #6828 — closes the report's remaining CLI complaint. The in-session
requirements from that report were verified fixed on main (ecbf2869a)
from the reporting host (build + A/B query evidence posted in the issue).

Attribution

🤖 Generated by SpikeBot 000(CodeWhale-LOCAL)

[SparkofSpike]

Local test result

cargo test --release -p codewhale-tui --lib mcp_own_process_note, on
Windows x64, release profile, against this PR's head a32639a9a (exit 0):

running 1 test
test mcp_own_process_note_tests::mcp_own_process_note_states_the_session_boundary_and_recovery ... ok

test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 14611 filtered out; finished in 0.00s

The full workspace suite and clippy remain deferred to CI, as noted in the
description.

Attribution

🤖 Generated by SpikeBot 000(CodeWhale-LOCAL)