fix(cli): @-file completion crash on Windows when paths aren't cp1252-decodable

The fuzzy @-file completer shells out to 'rg --files' via subprocess.run
with text=True. On Windows, Python 3.13 decodes stdout using the system
ANSI codepage (cp1252), so any filename containing bytes like 0x81/0x8f
crashes the background reader thread with UnicodeDecodeError. The
exception is swallowed inside subprocess, leaving proc.stdout=None, and
the next line ('proc.stdout.strip()') blows up with:

  AttributeError: 'NoneType' object has no attribute 'strip'

This takes down the prompt_toolkit event loop and forces 'Press ENTER to
continue' until the user clears the @-query.

Fix:
- Pass encoding='utf-8', errors='replace' so rg's UTF-8 output is decoded
  consistently across platforms and unmappable bytes don't crash.
- Guard 'proc.stdout' with a None check before .strip(), so a future
  reader-thread failure degrades gracefully instead of breaking input.

hermes_cli/commands.py

@@ -1362,9 +1362,9 @@ class SlashCommandCompleter(Completer):
             try:
                 proc = subprocess.run(
                     cmd, capture_output=True, text=True, timeout=2,
-                    cwd=cwd,
+                    cwd=cwd, encoding="utf-8", errors="replace",
                 )
-                if proc.returncode == 0 and proc.stdout.strip():
+                if proc.returncode == 0 and proc.stdout and proc.stdout.strip():
                     raw = proc.stdout.strip().split("\n")
                     # Store relative paths
                     for p in raw[:5000]: