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.

Beginne damit, den FileWatch-Host-Event-Pfad durch die JSON-RPC-Verarbeitung der Runtime und den IDE-Auto-Connect-Ablauf zu verfolgen; das Issue nennt keine bestimmten Quelldateien oder Tests. Reproduziere das Problem mit Debug-Logging unter Verwendung des bereitgestellten Workspace und der autoConnect-Einstellungen und überprüfe anschließend, dass wiederholt verworfene Events die TUI nicht mehr einfrieren und kein unbeschränktes Wachstum von CPU-Auslastung und Logs mehr verursachen.