The synchronous fuzzyFind() native call blocks the event loop during
@ file autocomplete. On large codebases (e.g. Java projects with deep
directory trees), each call can take seconds. Since updateAutocomplete()
was called on every keystroke while autocomplete was active, rapid typing
would cascade into dozens of blocking searches — freezing the TUI for
minutes. This made it appear that arrow keys caused the freeze, when
the actual cause was accumulated backlog from processing buffered input.
Debounce all @ file reference autocomplete paths (character input,
backspace, forward delete, and re-trigger after cancellation) with a
150ms delay so only the final keystroke triggers the expensive search.
Slash command autocomplete remains synchronous since it's cheap.
8b7b8bc651