[venkat1701]

BEGIN SERIALIZABLE recorded only reads by atom id or slot key. Reads that went through a posting list or an index range were never validated at commit, so these anomalies committed on both sides:

Anomaly (two interleaved sessions)	before	after
write skew through an indexed predicate (WHERE n.oncall = true, each turns a different one off)	both commit, 0 on call	second commit: serializable read of property-index … between 1 and 1 was invalidated
double booking through HAS (each sees the room free, each ADDs it to a different booking)	both commit	serializable read of the incident edges of atom 3 was invalidated
count-then-insert by type	caught only because both bumped the tenant usage counter	serializable read of the atoms of type 2 in tenant 0 was invalidated
count-then-insert by HAS	same accident	caught by the incidence read
absent canonical key read, then concurrent insert	not checked	caught by the canonical-key bucket

SNAPSHOT is unchanged: no dirty or non-repeatable reads, lost updates rejected, write skew allowed as in any snapshot isolation.

How

• Scan-style reads are recorded at the granularity they read and validated by content at commit:

  • an atom's reverse-index postings (incident, forEachIncidentEdge, incidentTree, degree);
  • a type's postings (atomsOfType, typeTree, countOfType);
  • a canonical-key hash bucket (resolve);
  • the key range of a property-index scan (View.nested), so changes outside the range do not conflict;
  • whole slots for unbounded scans (atoms(), scan(slot)).

  More than 8192 reads in one slot collapse into one whole-slot read. Promoted postings are compared by content, so a checkpoint between read and commit does not cause a conflict (tested).

• Reads that only steer a plan run in an explicit unrecorded scope (View.unrecorded()): planner estimates, HORA domain estimates, the single-tenant shortcut in Reader, and the eager quota check in Security.charge (the merge precondition still enforces the quota at commit). That last one also removes a false conflict between any two SERIALIZABLE transactions inserting in the same tenant. Results that depend on the same calls (degree(), count(*)) are still recorded.

• Nothing is recorded under SNAPSHOT; it allocates nothing new.

• docs/transactions/transactions.md section 6 describes the read kinds, granularity, false positives and the unrecorded scope, with an anomaly table.

Tests

• SerializableTest (13): each anomaly above conflicts under SERIALIZABLE; SNAPSHOT still allows write skew and prevents lost updates; no conflict for inserts of unrelated types, disjoint posting lists, changes outside an indexed range, or plan estimates on an index the plan did not use; degree() is still recorded. With the fix removed, 7 of them fail.
• SerializableReadsTest (engine, 8): every read kind on inline and promoted postings, with a checkpoint between read and commit, unchanged (commits by rebasing) and changed (conflicts); range pruning, own writes, promotion.
• Full build: engine 250, database 90, server 28, all passing.

Note for #108: it adds View.incidentCursor, which must record the same reverse-index read. I'll update #108 on top of this branch so the two cannot merge without it.