bug(plugin): an invalid memory identity turns memory off without saying so

[0xKT]

Summary

EverosBackend._validate_identity rejects a memory.userId / memory.agentId that
EverOS cannot accept -- the value becomes a directory segment on its write path -- by
raising ValueError from start(). Every call site of start() swallows it:

• raven/cli/agent_commands.py:402-407 and :499-505
• raven/cli/tui_commands.py:655-663
• raven/cli/gateway_commands.py:368-373

all wrap the call in except Exception: logger.exception("memory backend start failed; continuing with legacy memory path"). Under the TUI, loguru is redirected to a file
(tui_commands.py:1046), so an invalid identity turns long-term memory off with no
signal on screen at all. The agent REPL and the gateway do print the traceback, so the
silent case is the TUI specifically.

The same backend takes the opposite decision one function away: when the server is up but
embedding is unavailable, it prints to stderr through rich
(raven/plugin/memory/everos/backend.py:386,435) precisely because a file-only log is
not visible enough for a degraded-memory condition. An identity that disables memory
outright deserves at least as much.

Found by code review of #264 (see that PR's discussion) and deliberately not fixed there:
the four call sites are in files that branch does not touch, and the fix is either a
config-load-time validation or four changed except blocks, which is its own change.

Steps to reproduce

Derived from reading the code path, not reproduced at runtime.

1. Set an identity EverOS rejects in ~/.raven/config.json, e.g.
   "memory": {"userId": "team/alice"} (the guard requires
   ^[a-zA-Z0-9_.@+-]+$ and forbids . / ..).
2. Run raven tui.
3. Hold a conversation, then ask about something said earlier in a previous session.

Expected behavior

The wizard, raven doctor, or the first start says the identity is invalid and names the
userId key, the same way an unavailable embedding provider is reported on stderr.

Actual behavior

Startup continues, memory is off for the whole session, and the only record is a traceback
in ~/.raven/logs/. Recall returns nothing and store never runs, which reads as an agent
that simply does not remember.

Environment

Not environment-specific -- the visibility depends on which surface starts the backend
(TUI silent, agent REPL and gateway print). Observed while reviewing
feat/hermes_cold_start_import at 723ac26 on macOS / Python 3.12.

Logs or screenshots

Expected shape of the only surviving record:

ERROR ... memory backend start failed; continuing with legacy memory path
ValueError: memory.userId='team/alice' is not accepted by EverOS: it becomes a
directory segment on the write path, so it must match ^[a-zA-Z0-9_.@+-]+$ and must
not be '.' or '..'.

[AmirF194]

Reproduced the TUI-silent case with the real production pieces (not a mock): EverosBackend, PluginContext/ServiceLocator, and redirect_loguru_to_file called exactly as tui_commands.py:1080 calls it (terminal_level=None), wrapped in the same try/except _start_backend() uses at tui_commands.py:691-701.

Clean python:3.12-slim container, pip install -e ., HEAD 53aeb0cfd4b9c50f3611082e0ae635943945c056, user_id="team/alice":

=== what the TUI's own terminal would have shown ===
stdout: ''
stderr: ''

=== .../tui.log (file-only sink) ===
2026-08-09 07:08:07.692 | ERROR | __main__:_start_backend:37 - tui: memory backend start failed; continuing with degraded memory path
Traceback (most recent call last):
  File "repro_271.py", line 33, in _start_backend
    await backend.start()
  File "raven/plugin/memory/everos/backend.py", line 382, in start
    self._validate_identity()
  File "raven/plugin/memory/everos/backend.py", line 373, in _validate_identity
    raise ValueError(
ValueError: memory.userId='team/alice' is not accepted by EverOS: it becomes a directory segment on the write path, so it must match ^[a-zA-Z0-9_.@+-]+$ and must not be '.' or '..'.

Both streams are empty; only the file carries the record. Matches the report exactly.

One thing for whoever picks this up: git log -G on the try/except (commit 0465760, #71) shows it is deliberate, not an oversight. It exists to keep EverOS's lazy adapter warnings from corrupting the full-screen TUI (same reason redirect_terminal_fds_to_file runs alongside it). So a fix that prints straight to the live TUI or drops the swallow would reintroduce that corruption. The raven doctor/wizard route this issue already proposes is the one that does not fight that constraint.

Did not re-run the agent-REPL/gateway comparison: only read gateway_commands.py:150's terminal_level= and confirmed agent_commands.py has no redirect_loguru_to_file call, did not execute those two paths. The TUI case above is the one I actually ran.