v0.7.1

Omnigraph v0.7.1

A patch release on top of v0.7.0: three correctness fixes (camelCase filters,
cluster-apply crash loops, branch-merge OOM on embedding tables), one CLI
catalog-metadata improvement, and a warm-read performance fix. No breaking
changes, no on-disk format change, and no migration — drop-in over v0.7.0.

Fixes

• camelCase property filters now execute (#283). A query — or a chained
  mutation — that filtered on a camelCase schema field (e.g. repoName) linted
  and planned cleanly but failed at run time with No field named reponame. Column names are case sensitive. The identifier's case was destroyed at two
  engine→Lance boundaries: the read-filter pushdown built the column with a
  case-normalizing constructor, and the pending-batch mutation scan re-parsed
  the predicate through a normalizing SQL context. Both now preserve case (the
  read path uses a case-preserving column reference; the pending scan disables
  SQL identifier normalization), so camelCase fields work consistently in read
  and write predicates and a camelCase @index equality still routes to the
  scalar index. The fix is correct-by-construction rather than a per-query
  guard; a regression test pins index routing so a silent full-scan fallback
  can't slip back in.

• cluster apply no longer crash-loops a booting server (#284). Applying a
  schema change while a graph had non-main (agent/review) branches, or a
  migration that needed a backfill, could throw a freshly-booting
  omnigraph-server --cluster into an unescapable crash loop. Neither input is
  an engine bug — the engine rejects both cleanly and before moving any graph
  state — but cluster apply wrote a recovery sidecar before calling the
  engine and left it in place on the clean rejection, and the server refuses to
  boot while a sidecar is pending. The asymmetric-cleanup path is fixed so a
  pre-movement rejection leaves no stale sidecar, breaking the loop.

• Branch-merge fast-forward no longer OOMs on embedding tables (#277). A
  branch→main fast-forward merge of a forked, embedding-bearing table
  re-derived the whole branch through a single Lance merge_insert — a
  full-outer hash join over the entire delta — which exhausted the DataFusion
  memory pool on high-dimensional embeddings (e.g. 8k rows × 3072-dim) and hung
  or failed the merge. New rows now stream through stage_append (no hash
  join), only genuinely-changed rows are upserted, embeddings are no longer
  stringified to diff them, and index coverage defers to the reconciler, so a
  fast-forward merge completes in bounded work. The three-way merge path is
  unchanged.

Improvements

• omnigraph queries list surfaces stored-query @description /
  @instruction (#280). The CLI now shows a stored query's catalog metadata —
  what it does and how to invoke it — in both human and --json output,
  matching what GET /queries already returned. Previously both fields were
  silently dropped on the CLI side.

• Warm reads no longer pay an O(history) metadata tax (#268). Warm reads
  used to re-derive per-query metadata (coordinator re-open, __manifest +
  commit-graph re-scans, per-table re-open, double schema validation) on a cost
  that scaled with commit history and never warmed up. A warm same-branch read
  now does one cheap version probe, one schema read, and zero table opens on a
  warm repeat (warm coordinator reuse, open-by-location+version, validate-once,
  held Dataset handles + one shared Lance Session per graph). This also
  closes a commit-DAG fork where a same-branch write after an external commit
  could append off a stale cached head.

Upgrade notes

Drop-in over v0.7.0 — no configuration, schema, or data changes. Upgrade the
server and CLI together as usual. Graphs created on v0.7.0 read and write
identically on v0.7.1.