Runaway FileWatch host-event loop freezes TUI and grows debug log to 13 GB

Describe the bug

A long-running/resumed Copilot CLI session can enter a tight loop that emits:

[DEBUG] [rust:copilot_runtime::protocol::jsonrpc::engine] No connection accepted a host event {"kind":"FileWatch"}

Once the loop becomes continuous, the terminal UI stops responding while the
process consumes about two CPU cores and writes hundreds of KB/s to its debug
log.

In the affected process:

• The final 10,000 log records were all the identical discarded FileWatch
  event.
• Current CPU measured over five seconds was approximately 200%.
• RSS was approximately 1.1 GB.
• The process log had reached 13 GB and was growing at approximately 460 KB/s.
• The process remained alive; this was not an OS OOM kill or terminal flow
  control pause.
• The host had ample free memory, disk space, and inodes.
• USE_TGREP=false was already effective. Startup telemetry contained
  disabled_reason: "use_tgrep_false", and no tgrep child was running.

This appears related to IDE integration, but I cannot yet prove that opening
VS Code is the sole trigger. The affected session logged IDE lock-file watcher
startup and was running in a workspace open in VS Code. Disabling IDE
auto-connect prevented IDE discovery and the continuing event storm in a
controlled fresh-session test.

This differs from #3701: there was no repeated MCP server spawning or leaked
MCP process tree. The runaway activity was inside the Copilot process's
FileWatch/JSON-RPC event path.

Affected version

GitHub Copilot CLI 1.0.81-9

The no-IDE control test was also run after auto-update installed 1.0.81-11.

Steps to reproduce the behavior

The exact transition into the continuous loop is not yet deterministic, but
this is the observed setup:

1. Open a large multi-repository workspace in VS Code.
2. Start Copilot CLI from that workspace root with debug logging enabled.
3. Resume and continue using a long-lived session.
4. Leave IDE auto-connect enabled (the default).
5. The session eventually becomes unresponsive while its log continuously
   prints the discarded FileWatch event shown above.

Useful checks while the failure is active:

ps -p <pid> -o pid,pcpu,pmem,rss,nlwp,stat,wchan,cmd
tail -n 10000 ~/.copilot/logs/process-*.log |
  sed -E 's/^[0-9TZ:.-]+ \[[A-Z]+\] \[[^]]+\] //' |
  sort | uniq -c | sort -nr | head

The affected process showed:

10000 No connection accepted a host event {"kind":"FileWatch"}

Controlled comparison

I configured:

{
  "ide": {
    "autoConnect": false
  }
}

Then started a fresh CLI session from the same workspace while VS Code remained
open. In that session:

• There were no IDE lock watcher, IDE discovery, or ide_connected records.
• The process had no inotify watch on ~/.copilot/ide.
• Only five FileWatch records appeared during startup.
• Log growth then stopped, current CPU dropped to approximately 1%, and the TUI
  remained responsive.

For comparison, using the invalid dotted JSON key
"ide.autoConnect": false produced a settings warning, started the IDE lock
watcher, detected VS Code, and connected to the IDE. The nested object shown
above is required.

Expected behavior

• FileWatch events should be consumed, coalesced, debounced, or dropped without
  entering an unbounded CPU/logging loop.
• A disconnected/uninterested host-event consumer should not cause every
  filesystem event to be logged indefinitely.
• IDE lock-file activity should not starve terminal input or rendering.
• Debug logging should be rate-limited for repeated identical events.

Additional context

• OS: WSL2 Linux 6.6.87.2-microsoft-standard-WSL2
• Architecture: ARM64
• Terminal: VS Code integrated terminal
• Workspace root contained multiple repositories.
• Session indexing reported SESSION_INDEXING=true.
• tgrep was disabled with USE_TGREP=false.
• The affected process had two inotify descriptors resolving to the resumed
  session's own ~/.copilot/session-state/<session>/ and research/
  directories. The first FileWatch records also appeared before the log line
  that started the IDE lock-file watcher, so IDE auto-connect may be an
  amplifier or trigger rather than the underlying event source.
• Another session from the same environment previously accumulated a 2 GB log
  and approximately 4 GB RSS with large bursts of the same FileWatch message,
  but later became idle instead of remaining in the tight loop.

Workaround:

{
  "ide": {
    "autoConnect": false
  }
}

Restart Copilot CLI after applying the setting. Manual /ide connection
remains available.

Start by tracing the FileWatch host-event path through the runtime's JSON-RPC handling and the IDE auto-connect flow; the issue does not name specific source files or tests. Reproduce with debug logging using the supplied workspace and autoConnect settings, then verify that repeated discarded events no longer freeze the TUI or cause unbounded CPU and log growth.