Overhaul segment store: shared tables with incarnation-scoped tenant keys (port of #1548) - #1661

The existing context tests pass with the lateral's per-seed walk left
uncorrelated to its seed (only one filtered test, and it has one seed)
and with segments sharing a timestamp ordered by the wrong tie-breakers
(every test gives each segment its own timestamp). The new test reads
random contexts, several seeds at a time, with filters of every node
type, from a partition where many segments share a timestamp and
another partition holds segments at the same times, and compares each
result with an in-memory model that evaluates filters in SQL's logic.
Every partition is far smaller than the filtered read's window, so the
model has no bound.

It passes on both dialects here and at MemMachine#1661's tip, and fails on both
with the window ordered the same way on either side, with the filter
resolved against the table instead of the window, and with the
tie-breakers reordered, and on PostgreSQL with the walk uncorrelated.

Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>

Building the window's statement through an ORM alias adapted every
column the filter and the ordering read from it, and the walk went
through the mapped class. With a property filter that made building a
PostgreSQL request's two statements, with SQLAlchemy's cache key,
cost 1.6-1.8 ms of Python against 0.86 ms at MemMachine#1661's tip. The walk and
the window now use the table's and the window's own columns, and
SQLite's per-seed statements load segment rows through
select(SegmentRow).from_statement(), since building them from plain
rows cost more than ORM loading.

The SQL is byte-identical on both dialects. A filtered request now
takes 1.15-1.21 ms to build, of which about 0.3 ms is the window
itself: its subquery's columns and the larger statement to hash.
Filtered reads on PostgreSQL partitions of 200 and 2,000 segments,
20 seeds, went from 4-28% slower than MemMachine#1661's tip to 1-9%; SQLite
reads are unchanged.

Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>

…emMachine#1712)

A context read with a property filter selected, per seed and direction,
the first matching rows in walk order: ORDER BY the walk with the filter
in the WHERE clause and LIMIT the context size. The planner has no
statistics for property predicates; it estimates about one match per
seed, costs the ordered walk as reading the seed's whole side, and on
PostgreSQL plans a bitmap over that side and a sort instead. The read
then grew with the partition rather than with the context asked for.

With a filter, the context now comes from the seed's next 1,024
segments in walk order, read with no filter, and the filter and the
context size apply over those rows. The inner read has no filter to
misestimate, so it stays an ordered index scan, and it stops once the
context is found or the window ends. A match further than 1,024
segments from the seed is no longer context; the segment store ABC now
allows that bound. Unfiltered reads keep their statement. SQLite's
per-seed reads take the same window, so both dialects return the same
context.

Measured against MemMachine#1661's tip, 20 seeds per request with 2 segments back
and 4 forward, the rows of 21 partitions interleaved:

- PostgreSQL 16: a filtered request takes 8-12 ms instead of 4.5-7.1 s
  on a 1,000,000-segment partition, and 8-13 ms instead of 103-115 ms
  on 20,000-segment ones; unfiltered, 7.6 ms against 7.8 ms.
- SQLite, where the plan never read the whole side: filters matching
  20% or 1% take 1.1-1.2x as long as with the previous commit alone
  (14.1 vs 12.4 ms, 28.4 vs 24.2 ms), while a property that only the
  seeds carry takes 36 ms instead of 602 ms on a 200,000-segment
  partition, since the walk no longer runs toward the partition's end.
- For the same seeds, both dialects returned the same context as
  before, except where the bound applies: 12 forward with a filter
  matching every 100th segment returns the 10 matches within 1,024
  segments.

Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>

The existing context tests pass with the lateral's per-seed walk left
uncorrelated to its seed (only one filtered test, and it has one seed)
and with segments sharing a timestamp ordered by the wrong tie-breakers
(every test gives each segment its own timestamp). The new test reads
random contexts, several seeds at a time, with filters of every node
type, from a partition where many segments share a timestamp and
another partition holds segments at the same times, and compares each
result with an in-memory model that evaluates filters in SQL's logic.
Every partition is far smaller than the filtered read's window, so the
model has no bound.

It passes on both dialects here and at MemMachine#1661's tip, and fails on both
with the window ordered the same way on either side, with the filter
resolved against the table instead of the window, and with the
tie-breakers reordered, and on PostgreSQL with the walk uncorrelated.

Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>

Building the window's statement through an ORM alias adapted every
column the filter and the ordering read from it, and the walk went
through the mapped class. With a property filter that made building a
PostgreSQL request's two statements, with SQLAlchemy's cache key,
cost 1.6-1.8 ms of Python against 0.86 ms at MemMachine#1661's tip. The walk and
the window now use the table's and the window's own columns, and
SQLite's per-seed statements load segment rows through
select(SegmentRow).from_statement(), since building them from plain
rows cost more than ORM loading.

The SQL is byte-identical on both dialects. A filtered request now
takes 1.15-1.21 ms to build, of which about 0.3 ms is the window
itself: its subquery's columns and the larger statement to hash.
Filtered reads on PostgreSQL partitions of 200 and 2,000 segments,
20 seeds, went from 4-28% slower than MemMachine#1661's tip to 1-9%; SQLite
reads are unchanged.

Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>

validate_identifier matched `^[a-z0-9_]+$`, and `$` also matches before a
trailing newline, so "name\n" passed as a namespace, a collection name, and now
a vector store name that becomes part of the registry's table names. It uses
fullmatch, as MemMachine#1661 does for the segment store's partition keys. The event
backend's service locator already hashes such a session id: it checks session
ids with the segment store's validator, which uses fullmatch since MemMachine#1661.

Tests, each verified to fail with `match` restored: a vector store name with a
trailing newline is refused, and a namespace or collection name with one is
refused by both stores.

Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>

The registry is built and tested on PostgreSQL and SQLite only. On
another dialect it misbehaves rather than failing at construction: the
retention cutoff is PostgreSQL's interval arithmetic outside SQLite,
MySQL has no DELETE ... RETURNING, and on SQL Server SQLAlchemy drops
the claims' FOR UPDATE SKIP LOCKED without a word. The constructor now
refuses any other dialect with a ValueError, beside its vector store
name check, as MemMachine#1661 does in the segment store's engine validator.

Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>

…registry for

Equivalents of the segment store tests MemMachine#1661 adds, where the registry has the
same behavior, each verified to fail with that behavior removed and to pass
with it:
- a claim skips a tombstone another purger holds (PostgreSQL; fails with
  SKIP LOCKED dropped), as test_purge_skips_entries_claimed_by_concurrent_purger;
- racing deletions of one collection queue one tombstone and leave the name
  free, and a deletion racing another process's waits and then queues nothing
  (fail with a read before the DELETE), as test_concurrent_partition_deletes_are_clean
  and test_concurrent_remote_delete_yields_single_queue_entry;
- a mint colliding with a live incarnation is minted again, not reported as a
  taken name (fails with every integrity error read as a taken name), as
  test_incarnation_colliding_with_live_partition_is_never_reused;
- a mint colliding with a deletion in flight checks the queue after its insert
  (fails with the check moved before it), as
  test_mint_detects_collision_with_concurrent_deletion and its SQLite
  counterpart, staged by the insert being issued rather than by a sleep;
- a round claims one tombstone (fails without the LIMIT), as
  test_purge_claims_queue_entries_incrementally;
- a persistent database error surfaces with its cause chained (fails with the
  cause dropped), as test_persistent_integrity_error_surfaces_with_cause.
The existing test that an incarnation awaiting purge is never minted again, the
equivalent of test_incarnation_with_garbage_left_is_never_reused, was verified
the same way.

Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>

…cess

Milvus Lite does not arbitrate two creations of one collection racing in one
process: the loser fails with "[Errno 17] File exists", which is not an
already-exists error, so the logical creation raised. Every logical collection
of a namespace and configuration shares its native collection, so two sessions
created at once before it exists race on it (on main too, for different
names; the per-name locks this PR removed had covered the same name). The
store now takes a per-process lock per native collection around the existence
check and the creation; the later creator finds the collection. Creation stays
idempotent across processes as before.

The contract gains a lifecycle churn test, the equivalent of MemMachine#1661's
test_lifecycle_churn_completes_without_database_errors: concurrent create,
open-or-create, open and delete of a few names raise nothing but the domain's
own outcomes. It found this on Milvus Lite and fails there without the lock.

Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>

…ifecycle for

Equivalents of the segment store tests MemMachine#1661 adds, in the lifecycle contract
both stores run (Qdrant in-memory, REST and gRPC; Milvus Lite), each verified
to fail with the behavior removed and to pass with it:
- a read checks the registry once, before it, and a write twice, around it
  (fails with a check after a read, or without the check after a write), as
  test_reads_check_liveness_inside_the_data_statement pins the segment store's
  registry round trips per operation;
- a creation that fails at the native collection registers nothing, for
  create_collection and open_or_create_collection (fails with the registry
  written first), as test_unloadable_codec_config_commits_no_registry_row;
- open-or-create gives up after a bounded number of lost races (fails without
  the bound), and creates again when the winner it lost to is gone (fails if
  that case raises), as the lost-race arm of
  test_persistent_mint_failure_raises_instead_of_looping;
- deletion leaves the records for the purge (fails if deletion reclaims them
  itself), as test_delete_partition_touches_only_registry_and_queue: the purge
  test asserted the records unreachable but not still held.

Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>

validate_identifier matched `^[a-z0-9_]+$`, and `$` also matches before a
trailing newline, so "name\n" passed as a namespace, a collection name, and now
a vector store name that becomes part of the registry's table names. It uses
fullmatch, as MemMachine#1661 does for the segment store's partition keys. The event
backend's service locator already hashes such a session id: it checks session
ids with the segment store's validator, which uses fullmatch since MemMachine#1661.

Tests, each verified to fail with `match` restored: a vector store name with a
trailing newline is refused, and a namespace or collection name with one is
refused by both stores.

Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>

The registry is built and tested on PostgreSQL and SQLite only. On
another dialect it misbehaves rather than failing at construction: the
retention cutoff is PostgreSQL's interval arithmetic outside SQLite,
MySQL has no DELETE ... RETURNING, and on SQL Server SQLAlchemy drops
the claims' FOR UPDATE SKIP LOCKED without a word. The constructor now
refuses any other dialect with a ValueError, beside its vector store
name check, as MemMachine#1661 does in the segment store's engine validator.

Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>

…registry for

Equivalents of the segment store tests MemMachine#1661 adds, where the registry has the
same behavior, each verified to fail with that behavior removed and to pass
with it:
- a claim skips a tombstone another purger holds (PostgreSQL; fails with
  SKIP LOCKED dropped), as test_purge_skips_entries_claimed_by_concurrent_purger;
- racing deletions of one collection queue one tombstone and leave the name
  free, and a deletion racing another process's waits and then queues nothing
  (fail with a read before the DELETE), as test_concurrent_partition_deletes_are_clean
  and test_concurrent_remote_delete_yields_single_queue_entry;
- a mint colliding with a live incarnation is minted again, not reported as a
  taken name (fails with every integrity error read as a taken name), as
  test_incarnation_colliding_with_live_partition_is_never_reused;
- a mint colliding with a deletion in flight checks the queue after its insert
  (fails with the check moved before it), as
  test_mint_detects_collision_with_concurrent_deletion and its SQLite
  counterpart, staged by the insert being issued rather than by a sleep;
- a round claims one tombstone (fails without the LIMIT), as
  test_purge_claims_queue_entries_incrementally;
- a persistent database error surfaces with its cause chained (fails with the
  cause dropped), as test_persistent_integrity_error_surfaces_with_cause.
The existing test that an incarnation awaiting purge is never minted again, the
equivalent of test_incarnation_with_garbage_left_is_never_reused, was verified
the same way.

Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>

…cess

Milvus Lite does not arbitrate two creations of one collection racing in one
process: the loser fails with "[Errno 17] File exists", which is not an
already-exists error, so the logical creation raised. Every logical collection
of a namespace and configuration shares its native collection, so two sessions
created at once before it exists race on it (on main too, for different
names; the per-name locks this PR removed had covered the same name). The
store now takes a per-process lock per native collection around the existence
check and the creation; the later creator finds the collection. Creation stays
idempotent across processes as before.

The contract gains a lifecycle churn test, the equivalent of MemMachine#1661's
test_lifecycle_churn_completes_without_database_errors: concurrent create,
open-or-create, open and delete of a few names raise nothing but the domain's
own outcomes. It found this on Milvus Lite and fails there without the lock.

Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>

…ifecycle for

Equivalents of the segment store tests MemMachine#1661 adds, in the lifecycle contract
both stores run (Qdrant in-memory, REST and gRPC; Milvus Lite), each verified
to fail with the behavior removed and to pass with it:
- a read checks the registry once, before it, and a write twice, around it
  (fails with a check after a read, or without the check after a write), as
  test_reads_check_liveness_inside_the_data_statement pins the segment store's
  registry round trips per operation;
- a creation that fails at the native collection registers nothing, for
  create_collection and open_or_create_collection (fails with the registry
  written first), as test_unloadable_codec_config_commits_no_registry_row;
- open-or-create gives up after a bounded number of lost races (fails without
  the bound), and creates again when the winner it lost to is gone (fails if
  that case raises), as the lost-race arm of
  test_persistent_mint_failure_raises_instead_of_looping;
- deletion leaves the records for the purge (fails if deletion reclaims them
  itself), as test_delete_partition_touches_only_registry_and_queue: the purge
  test asserted the records unreachable but not still held.

Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>

validate_vector_store_name matched `^[a-z0-9_]+$`, and `$` also matches
before a trailing newline, so "name\n" passed as a vector store name, which
names the native Qdrant or Milvus collection and is part of the SQLite
stores' table names. It uses fullmatch, as validate_identifier does for
partition keys and MemMachine#1661 does for the segment store's.

The rule had no test: valid names pass, and an empty name, an uppercase
letter, a hyphen, a trailing newline and a name one byte over the bound
are refused. The trailing-newline case fails with `match` restored.

Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
Claude-Session: https://claude.ai/code/session_01ESpWYTmCR7X3bJEpoA8SAn

…1712) (#1713)

* Build SQLite's context statements once per request, binding each seed's position

SQLite's context reads run two statements per seed, and each was built
per seed with the seed's walk position as literals. Building a
statement and computing its cache key costs several times what SQLite
takes to run it: 0.16 ms against 0.04 ms per statement on a
200,000-segment partition, for a filtered statement. Each direction's
statement is now built once per request and run per seed with the
position bound. With 20 seeds, 2 back and 4 forward, a request takes
11.7 ms instead of 15.3 ms unfiltered and 12.4 ms instead of 17.0 ms
with a property filter matching 20% (p50, one client).

Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>

* Take filtered context from a bounded window next to each seed (fixes #1712)

A context read with a property filter selected, per seed and direction,
the first matching rows in walk order: ORDER BY the walk with the filter
in the WHERE clause and LIMIT the context size. The planner has no
statistics for property predicates; it estimates about one match per
seed, costs the ordered walk as reading the seed's whole side, and on
PostgreSQL plans a bitmap over that side and a sort instead. The read
then grew with the partition rather than with the context asked for.

With a filter, the context now comes from the seed's next 1,024
segments in walk order, read with no filter, and the filter and the
context size apply over those rows. The inner read has no filter to
misestimate, so it stays an ordered index scan, and it stops once the
context is found or the window ends. A match further than 1,024
segments from the seed is no longer context; the segment store ABC now
allows that bound. Unfiltered reads keep their statement. SQLite's
per-seed reads take the same window, so both dialects return the same
context.

Measured against #1661's tip, 20 seeds per request with 2 segments back
and 4 forward, the rows of 21 partitions interleaved:

- PostgreSQL 16: a filtered request takes 8-12 ms instead of 4.5-7.1 s
  on a 1,000,000-segment partition, and 8-13 ms instead of 103-115 ms
  on 20,000-segment ones; unfiltered, 7.6 ms against 7.8 ms.
- SQLite, where the plan never read the whole side: filters matching
  20% or 1% take 1.1-1.2x as long as with the previous commit alone
  (14.1 vs 12.4 ms, 28.4 vs 24.2 ms), while a property that only the
  seeds carry takes 36 ms instead of 602 ms on a 200,000-segment
  partition, since the walk no longer runs toward the partition's end.
- For the same seeds, both dialects returned the same context as
  before, except where the bound applies: 12 forward with a filter
  matching every 100th segment returns the 10 matches within 1,024
  segments.

Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>

* Rename the context reads' ordering helper to _chronological_order

The helper orders segment rows by their chronological columns
(timestamp, event, index, offset), newest first when descending, the
order the store's context reads called chronological_order before
the window. _walk_order named no column or direction. The window
query's docstring now says its result comes nearest the seed first,
which holds on both sides.

Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>

* Bound filtered context reads at 1,000 segments per side, not 1,024

Nothing depends on a power of two here: the bound is a LIMIT on the
segments a filtered context read takes per seed and side, and 1,000
is the round number.

Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>

* Build each context statement's walk in _context_rows_query

Both context reads built the same walk before handing it to
_context_rows_query: the partition's segments past the seed on one
side, nearest first. _context_rows_query now takes the seed's ordering
values and the side, and builds the walk itself. Its callers pass only
what differs between them, bound parameters on SQLite and the seeds
subquery's columns on PostgreSQL, and no longer pair a range condition
with a direction flag that has to agree with it.

The walk carries the partition's liveness check, so every context
statement carries it from one place. PostgreSQL's statement had it in
its seeds subquery, which drops it; otherwise its SQL is unchanged, and
SQLite's is byte-identical. correlate_except(SegmentRow) replaces the
lateral's two correlate(seeds_subquery) calls: only the walk needed
one, when a property filter nests it in the window.

Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>

* Shorten _context_rows_query's docstring to its contract

The docstring now says what the statement selects, what the seed's
ordering values may be, what the window bounds and why it is read
without the filter, and that a deleted partition yields nothing. The
account of how an unestimated filter turns the walk into a read of the
seed's whole side stays in the PR and #1712.

Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>

* Pass the context helpers' flags and bounds by keyword

Calls like _context_rows_query(values, True, max_backward_segments,
property_filter) did not say what True or the bound were. The side,
limit and filter of _context_rows_query and of the lateral's
per-direction helper, _chronological_order's descending, and
_resolve_segment_field's row are now keyword-only; each helper's
subject (the seed's ordering values, the row, the field) stays
positional.

Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>

* Say plainly why SQLite's context statements are built once per request

The comment now names what is bound per seed (its timestamp, event
UUID, index and offset) and why: building a statement costs more CPU
than SQLite spends running it, so building one per seed would dominate
the read.

Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>

* Test context reads against a model of the timeline

The existing context tests pass with the lateral's per-seed walk left
uncorrelated to its seed (only one filtered test, and it has one seed)
and with segments sharing a timestamp ordered by the wrong tie-breakers
(every test gives each segment its own timestamp). The new test reads
random contexts, several seeds at a time, with filters of every node
type, from a partition where many segments share a timestamp and
another partition holds segments at the same times, and compares each
result with an in-memory model that evaluates filters in SQL's logic.
Every partition is far smaller than the filtered read's window, so the
model has no bound.

It passes on both dialects here and at #1661's tip, and fails on both
with the window ordered the same way on either side, with the filter
resolved against the table instead of the window, and with the
tie-breakers reordered, and on PostgreSQL with the walk uncorrelated.

Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>

* Build context statements from Core columns

Building the window's statement through an ORM alias adapted every
column the filter and the ordering read from it, and the walk went
through the mapped class. With a property filter that made building a
PostgreSQL request's two statements, with SQLAlchemy's cache key,
cost 1.6-1.8 ms of Python against 0.86 ms at #1661's tip. The walk and
the window now use the table's and the window's own columns, and
SQLite's per-seed statements load segment rows through
select(SegmentRow).from_statement(), since building them from plain
rows cost more than ORM loading.

The SQL is byte-identical on both dialects. A filtered request now
takes 1.15-1.21 ms to build, of which about 0.3 ms is the window
itself: its subquery's columns and the larger statement to hash.
Filtered reads on PostgreSQL partitions of 200 and 2,000 segments,
20 seeds, went from 4-28% slower than #1661's tip to 1-9%; SQLite
reads are unchanged.

Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>

* Annotate column collections with the documented ColumnCollection

ReadOnlyColumnCollection, what FromClause.c returns, is importable only
from sqlalchemy.sql.base and has no entry in SQLAlchemy's documentation.
ColumnCollection, its base class, is documented and exported from
sqlalchemy. Annotations only.

Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>

* Bound every context read at the same distance, filtered or not

The SegmentStore ABC allowed a bound only on filtered context. It now
allows an implementation-defined bound on how many of the segments
nearest each seed context may come from, whatever the filter: a segment
that far from its seed is not a neighbor either way, and a hard bound
keeps every context read's cost bounded.

The store applies its window to unfiltered reads too by capping their
limit at it: an unfiltered read already reads exactly its context size,
so the cap needs no window subquery and costs nothing. The constant is
renamed _MAX_CONTEXT_DISTANCE, and the window's test now checks that an
unfiltered read stops at the bound; it fails with the cap removed.

Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>

* State the context bound as the caller's contract

The ABC now says what a caller can rely on, that each side's context
may be limited to an implementation-defined number of the segments
nearest the seed, rather than describing what an implementation does
beyond the bound.

Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>

* State the context bound as what a caller can observe

The ABC now says only that an implementation may bound how far from
each seed it looks for context, so a side can come back with fewer
segments than requested even when more exist further away. It no longer
says how the bound is counted, so it neither reads as though context
might not match property_filter nor rules out an implementation with no
bound or with a bound on matching segments.

Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>

* Build SQLite's context statements only for the sides a read asks for

The loop built both directions' statements on every read and ran each
only when its side asked for segments, so a read with no backward
context (expand_context of 1 or 2) built a statement it never used.
Each statement is now built only when its side asks for segments, as
the PostgreSQL path already does.

Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>

* Test the context bound with several seeds, filters and ties

The bound test used one seed, and the model test's partitions never
reached the bound, so no test exercised the bound with several seeds,
filters and shared timestamps together. Each model-test read now sets
the bound at random, from one segment to the default, and the model
applies it before the filter: the nearest segments on each side, then
the filter and the requested count.

Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>

* Load PostgreSQL's context rows through the ORM

The lateral path built each context row by hand, passing ten keyword
arguments to SegmentRow's instrumented constructor, as main did. It now
selects each seed's UUID next to SegmentRow aliased to the lateral
subquery, so the ORM loads the rows, as the SQLite path does. The SQL
selects the same columns plus incarnation, and the contexts are
identical.

Measured against the previous commit in one quiet window, arms
alternated (20 seeds, 2 back and 4 forward unless noted): p50 at one
client 14-22% lower with a filter on the 1M-segment partition and the
20k one with a 20% filter (7.6 to 5.9 ms with 20%; 22.2 to 19.0 ms
with 1%, 4 back and 12 forward), and requests/s at 16 clients 26-39%
higher in every scenario. Building a request's two statements takes
0.95-0.98 ms with a filter instead of 1.18-1.22 ms, and 0.46-0.48 ms
without one instead of 0.74-0.78 ms, since the select list is one
entity instead of ten columns.

Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>

* Resolve filter fields against columns only

_resolve_segment_field took either the mapped class or a column
collection, defaulting to the class, because the seeds query passed the
class and the window passed its columns. The seeds query now passes the
table's columns too, so the resolver takes one kind of argument, named
columns like _chronological_order's, with no default, and no longer
needs .expression for the timestamp column. The compiled SQL is
unchanged on both dialects.

Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>

* Read SQLite's context one direction at a time, as PostgreSQL does

The loop built and ran the backward and forward statements in two
near-identical blocks each. It now has the PostgreSQL path's shape: a
per-direction function that builds the direction's statement once and
runs it for every seed, called for a side only when that side asks for
segments. The statements are the same; all of a read's backward
statements now run before its forward ones.

Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>

* Revert "Test the context bound with several seeds, filters and ties"

This reverts commit 745c679. The bound's size is not part of the
contract, and bounds of a few segments are not realistic use. The
bound test already fails with the window's limit off by one or removed
and with the unfiltered cap removed, and the model test, without a
bound, already fails on PostgreSQL with a seed's walk uncorrelated to
its seed, the multi-seed risk the random bounds were meant to cover.

Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>

* Draw the model test's identifiers from its seeded generator

The model test's timestamps, properties, seeds and filters came from a
seeded generator, but segment, event and derivative identifiers came
from uuid4(), so which of two events sharing a timestamp came first
changed from run to run. They now come from the same generator, so
every run generates the same data. _seg takes an optional uuid for it.

Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>

* Revert "Draw the model test's identifiers from its seeded generator"

This reverts commit 9aac74f. The seeded generator already makes every
run test the same cases: the timestamps, properties, seeds, context
sizes and filters. Identifiers stay random UUIDs from uuid4(); they
only decide which of two events sharing a timestamp sorts first, which
the model orders the same way.

Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>

* Give the model test's events sorted random UUIDs

Events sharing a timestamp are ordered by their UUIDs, which came from
uuid4() in generation order, so their order changed from run to run.
The test now draws its events' UUIDs from uuid4(), sorts them, and
hands them out in generation order, so every run tests the same cases,
including the order of tied events, while the UUIDs stay random.

Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>

---------

Co-authored-by: Claude Opus 5.5 (1M context) <[email protected]>

From an audit against the PR's writing rules, across the seven vector
store design documents:
- They narrated changes and PRs (what "is gone", what the configuration
  "gains" and "loses", what MemMachine#1627, MemMachine#1663, MemMachine#1625, MemMachine#1661 and MemMachine#1671 do, and
  "the previous design"), and claimed MemMachine#1468 fixed by two PRs that are
  open. Each now states the design, keeping links to open issues.
- They had drifted from the code: a delete checks liveness once, after
  its call; Qdrant has no load step and Milvus loads on every
  preparation; the handle's writes run with qdrant-client's default
  wait rather than passing it; the Qdrant store states no replicated
  read delay; and the purge contract promises bounded work per call,
  while oldest-first rounds are the registry-backed stores'.
- Repetition across documents goes: the clients section, the replicated
  Qdrant measurements and the Qdrant id alternatives now live in one
  document each, linked from the others; consistency cites the Strong
  wait's measurement instead of a figure without its conditions; the
  async-client measurement names its Milvus version.
- The UUID text form, a string format rather than a design decision,
  is gone from the isolation document.

Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>