bug(memory): the EverOS server is resolved from PATH, not from raven's own environment

[arelchan]

Summary

raven/plugin/memory/everos/_server.py:60 resolves the EverOS server executable from
PATH:

everos = shutil.which("everos")
if not everos:
    raise RuntimeError("everos not found. Please install the everos CLI.")

But EverOS is a pinned hard dependency of raven itself (pyproject.toml:37,
everos[multimodal]==1.2.1), so the server raven launches has to be that copy. Asking
PATH for it is wrong in both directions.

Nobody gets an EverOS on PATH by installing raven

uv tool install only links the entry points of the named package. Measured on a machine
where raven is installed that way:

$ uv tool list
raven v0.1.9
- raven          <- the only exposed entry point

The dependency's own console script does exist, at
~/.local/share/uv/tools/raven/bin/everos, but it is never linked into ~/.local/bin
and the tool venv's bin/ is not on PATH when ~/.local/bin/raven runs.

So on a clean machine shutil.which("everos") returns None, ensure_everos_server
raises, and the memory backend does not start. The message it raises tells the user to
"install the everos CLI", which is misleading: raven already ships one, and installing a
second, independently-versioned copy is what causes the failure below.

And when something else is on PATH, raven launches a stranger

If any other EverOS exists on PATH -- for example a separately installed
uv tool install everos -- raven launches that binary instead of its own. On the machine
this was found on:

raven's own venv      everos 1.2.1   (the pinned dependency; client speaks /api/v2)
~/.local/bin/everos   everos 1.1.3   (a separate uv tool; server only serves /api/v1)

raven started the 1.1.3 server, then spoke v2 to it. See the sibling issue on the health
probe for why that pairing was never detected, and the one on swallowed store failures
for why it ran that way for a week without a visible symptom.

Note that released raven 0.1.9 vendors everos 1.1.3, so client and server agree there;
the cross-version pairing became possible when the dependency was raised to 1.2.1, whose
client uses /api/v2 (backend.py:253, :279). This is a problem shipping in the next
release rather than one already in users' hands.

Suggested fix

Resolve the interpreter's own environment first and fall back to PATH:

candidate = Path(sys.executable).parent / "everos"
everos = str(candidate) if candidate.exists() else shutil.which("everos")

If neither exists, the error should say the raven installation looks incomplete (its
pinned dependency is missing) rather than instructing the user to install a separate CLI.

Environment

• macOS 15.3, raven from uv tool install
• raven source tree pins everos[multimodal]==1.2.1; installed raven 0.1.9 carries 1.1.3

[arelchan]

Part of one investigation: #318 (wrong binary launched) -> #319 (wrong binary adopted undetected) -> #320 (the resulting per-turn failures stay invisible). Neighbouring existing issues: #271 (start-time identity failure swallowed), #191 (user-side report of EverOS misconfiguration).