Keep every message of a batched ingest, and fix three extraction defects

[bjmeetsfo]

main currently loses messages on a batched ingest, and its own test says so.
test_batch_event_integrity fails on clean main with 2 failures — the test was
merged but the fix behind it never was.

Measured on this branch's base: a six-message batch retained one message.

kept:  'user: I am a robotics engineer at Acme.'
lost:  the other five

Three commits, in the order they have to land.

1. Keep every message of a batch ingest

The sync-accept path writes ONE pending event for the whole envelope; the commit path
re-emits one event PER MESSAGE from source_event_ids, and skipped any message whose
index ran past that list:

for index, message in enumerate(envelope["messages"]):
    if index >= len(source_event_ids):
        continue

A batch arrives with one source id for N messages, so N−1 were dropped. Worse, the one
re-emitted event reused source_event_ids[0], so latest-value compaction replaced the
full pending event with a short one holding only the first message. Nothing errored and
the call returned accepted.

Messages past the supplied ids now derive an id exactly as the non-derived branch does —
stable for the same batch and message position — so a batch leaves one event per message
with distinct ids. Distinct ids matter independently: reusing one id is what let
compaction hide the loss.

test_batch_event_integrity goes from 2 failures to green.

2. Three extraction and ingest defects

The location pattern ran to the end of the sentence. "I live in Seattle and prefer metric units" stored the location as "Seattle and prefer metric units", which then
polluted the profile summary text carrying cross-session memory. It now stops at the
clause boundary. Verified on main's own extractor: the value is Seattle.

One preference became two entities, then four. Two extractors fire on one clause and
produce different entity_names, so the name-keyed dedupe never saw them as one — and
promotion to the profile node doubled both again. The PLAIN entity is the one kept: its
name is the bare entity type, which is the stable identity cross-session supersession
matches on, where the directive name embeds its own text and cannot supersede a later
correction.

The batched-ingest warning is removed — but only because commit 1 above makes it
false. It told callers a batch retains ~1 raw event and loses the rest, which is
accurate on main today. Removing it without the fix would have deleted a true warning;
that ordering is why these ship together.

3. Make the equivalence test deterministic

The test replacing that warning failed roughly one run in three, for two reasons. It
asserted equality on a summary count that legitimately varies — node_l1_generation_policy
gates L1 on event_count, so a bundled call and per-turn calls evaluate that gate at
different counts. And it raced the background embedding worker, which returned 19–22
embedding records against a steady 18. It now compares the retention-critical types only
and waits for the record count to settle.

Verification

• test_batch_event_integrity — 2 failures → green
• test_matrixark_profile_scope_warning + test_batch_event_integrity — 4/4 runs green, checked repeatedly because one commit is a flake fix
• Full suite failing-name diff against clean main: one name fixed, one appears — test_retrieval_audit_is_off_by_default, verified to fail identically on clean main (a run-context artifact, not caused here)

Conflict resolution notes

Two hunks needed resolving, both kept minimal on purpose:

• matrixark_local_adapter_ingest.py — kept CALLER_SUPPLIED_EVENT_FIELDS, which main
  gained independently, and dropped only the warning block.
• matrixark_mcp_core.py — bounded main's existing location pattern. The incoming side
  also carried a capitalised-location and a relationship pattern from earlier commits that
  were never mirrored; bringing those in would have smuggled unrelated changes into a
  bug-fix PR, so they were left out.