test(db-parity): LadybugDB intermittently writes 51 fewer CONTAINS edges under runner load #1612

Database Parity Check is failing intermittently on main. Every metric matches across all four backends except REL_CONTAINS, where LadybugDB comes up short:

Metric          | KuzuDB | LadybugDB | FalkorDB | Neo4j | Match?
REL_CONTAINS    | 4600   | 4549      | 4600     | 4600  | NO

All node counts, REL_CALLS (664 total / 653 distinct / 11 duplicates), REL_INHERITS, REL_IMPORTS and REL_HAS_PARAMETER match exactly. It is only CONTAINS, and only Ladybug.

It is not a code regression

The same commit passes and fails depending on the run:

ladybug resolves to 0.19.1 in both (released 2026-08-04, before either run), so it is not a dependency bump.

It correlates with runner load

The failing runs were markedly slower across every backend:

              KuzuDB   LadybugDB   FalkorDB   Neo4j
passing run   168.07      102.80      19.45   48.12
failing run   213.36      118.34      20.57   47.27

Kuzu +27%, Ladybug +15%, on an otherwise identical workload. That points at a load- or timing-dependent drop in the write path rather than anything deterministic about the graph.

Likely mechanism

Probably the same root cause as #1605: database_embedded_kuzu.py:743-757 deliberately forces a per-row fallback for relationship writes inside UNWIND to dodge a Kùzu planner bug. CONTAINS is by far the highest-volume relationship here (4600 vs 664 for the next biggest), so it is the most exposed to per-row write pressure — and LadybugDB is the Kùzu fork, sharing that path.

Losing 51 of 4600 edges (~1.1%) silently, with no error surfaced, is the part that matters most: the same drop would occur on user indexes and nothing would report it.

Suggested next steps

1. Confirm whether the write path swallows an error — a per-row failure that is caught and logged at debug level would explain a silent partial write.
2. Check whether the deficit is a stable 51 or varies with load; that distinguishes a truncation boundary from a race.
3. Consider whether perf(kuzu): relationship batching is disabled, degrading every batched write to one query per row #1605's batching work removes this class of problem entirely.

Until then Database Parity Check will be red on main intermittently, which makes it easy to start ignoring — worth prioritising for that reason alone.