build(everos-memory): hold everos to the 1.4 line instead of pinning 1.2.3

[0xKT]

Summary

The everos-memory plugin depended on everos[multimodal]==1.2.3. It now takes everos[multimodal]>=1.4.1,<1.5.

Why now: everos 1.4.1 (2026-09-24) pins openai<3, which a fresh install needs since openai 3.x shipped the same day and broke every LLM and embedding call. everos 1.4.0 brings native Windows support and IVF_FLAT indexes on the vector columns.

Policy change, decided with the maintainer: the pin moves from one exact version to one minor line. A patch release may now follow through uv lock --upgrade; a minor or major bump stays a deliberate, re-validated event. The lock still names one exact version and the release's raven-constraints.txt is exported from it, so an install from a release gets exactly the validated version. Section 7.1 and 7.2 of docs/memory-plugin-architecture.md describe the range and the uv add --package everos-memory ... step; section 7.4 records this upgrade.

Lock delta, five entries:

package	before	after
everos	1.2.3	1.4.1
everalgo-boundary	0.2.0	0.2.1
everalgo-core	0.4.0	0.3.0 (everos pins it exactly since 1.3.0)
pyarrow	24.0.0	25.0.1
msvc-runtime	-	14.44.35112, Windows only

Assessment against the adapter: every everos-internal symbol the adapter and the doc list is present in 1.4.1 (checked in both wheels), MemorizeAddRequest.messages still carries min_length=1, and the subject_vector column that 1.4.0's startup schema check requires already existed in 1.2.3, so no data migration. The adapter code does not change; two version citations in a docstring and a test docstring move from 1.2.3 to 1.4.1.

Not in this PR: lifting the native-Windows gate in the plugin now that everos 1.4.0 runs there (#176). That is its own change.

Type

• Fix
• Feature
• Docs
• CI / tooling
• Refactor
• Other

Verification

Run from a checkout of this branch with its own environment (uv sync --all-packages, which installs everos 1.4.1):

uv run pytest tests/test_everos_plugin_discovery.py tests/test_everos_backend.py \
  tests/test_everos_http_adapter.py tests/test_memory_backend_protocol.py \
  tests/test_memory_backend_contract.py tests/test_everos_server.py \
  tests/test_everos_config.py tests/test_everos_discover.py tests/test_plugin_tools.py -q
# 448 passed, 1 skipped (inotify is Linux-only) in 59s, everos 1.4.1 installed

uv run pytest tests/integration/test_everos_backend_e2e.py -m real_llm -q -rs
# 3 failed: the in-process drain in tests/integration/conftest.py reads a sqlite file with no
# md_change_state table. The same three fail identically on main with everos 1.2.3, so this is a
# pre-existing harness failure, not this change; tracked separately.

make lint-python
# ruff check: All checks passed; ruff format --check: already formatted

uv run --all-extras pytest -q
# 26397 passed, 108 skipped, 2 failed in 6m44s. Both failures reproduce on main without this
# change: tests/test_rpc_files.py::test_a_host_without_libreoffice_says_so answers 500 instead
# of 503 on this macOS host, and tests/test_shell_background.py::test_the_background_child_gets_
# the_baseline_env_not_the_host_env passes when run alone (a timing flake under the parallel run).

make check-large-files
# no added or modified file over 1 MiB in origin/main..HEAD

• Relevant tests pass locally
• Relevant lint / type checks pass locally
• User-facing docs or screenshots are updated when needed

Risk

• Security impact considered
• Backward compatibility considered
• Rollback path is clear for risky changes

Dependency bump only, no new network surface; 1.4.1's openai<3 pin removes a fresh-install failure. An index written by 1.2.3 opens under 1.4.1 unchanged. User-visible differences on an existing store: the first server start builds a vector index on every column past 2000 rows (seconds per 10k rows, searches keep working meanwhile), and ranking can shift slightly because vector search has used cosine on every path since 1.3.0. POST /memory/add answers 422 instead of 500 to a role = "tool" message without tool_call_id; the adapter already treats any status error as that one write refused.

Rollback: revert this PR and uv sync. No data rollback is needed because nothing migrated.

Related Issues

#176

[gloryfromca]

No blockers; this can merge as far as I am concerned.

I reviewed the full github/main...HEAD diff and the surrounding dependency, adapter, and release-export paths. The declared >=1.4.1,<1.5 range resolves to the checked-in 1.4.1 lock, and the release command still exports everos==1.4.1 while omitting workspace packages, so release installs remain exact. The source edits beyond dependency metadata are documentation-only version updates; no tests were weakened.

Coverage included the repository rules in AGENTS.md/CLAUDE.md and CONTEXT-MAP.md, the diff, callers/consumers, relevant history, backward compatibility, and architecture constraints. I found no rule or domain-vocabulary conflict.

Verification: uv lock --check, the locked constraints export, git diff --check, source-language check, and large-file check passed. All GitHub checks are green, including all four unit-test shards. A fresh local test environment did not finish downloading/extracting PyArrow in a reasonable time, so I did not count that interrupted attempt as a test result.