Let a filtered-out seed still anchor its segment context - #1498

Problem

get_segment_contexts applies property_filter to the seed lookup itself. A seed that does not match the filter is dropped before its window is built, so the caller gets nothing back for it — not even the neighbouring segments that do match.

The practical effect: a filter that excludes only the seed's own kind answers "no context" rather than "here is the surrounding context, of the kind you asked for". Asking to see the tool results around a message returns nothing, because the message is not a tool result.

Change

The seed is an address, not a candidate. It is looked up unfiltered so it can anchor its window wherever it is, and the filter is applied to it like any other row on the way out:

• returned when it passes, omitted when it does not;
• a seed whose entire window is filtered away stays absent from the returned mapping rather than mapping to an empty list, which the dict[UUID, list[Segment]] return already expresses unambiguously for multiple seeds.

Deciding whether each seed passes costs one indexed lookup over the seeds alone, and only when a filter is present.

Caller that assumed otherwise

EventMemory.build_query_result_context located the seed inside its own context with a bare next(...), which would now raise StopIteration. It falls back to the start of the context, degrading seed-proximity ordering to chronological order for that context.

I checked the rest of the tree for the same assumption; this was the only place.

Tests

Two new cases — the filtered-out seed keeps its window, and an entirely filtered window leaves the seed absent — running against SQLite and PostgreSQL, since both must have the same semantics.

Full event_memory suite, with and without the change, fails exactly the same 8 tests on this machine (all missing NLTK punkt_tab data, unrelated), and passes 4 more with it.

🤖 Generated with Claude Code