bug: any insert into a type with a camelCase @unique property fails — uniqueness lookup sends the column name unquoted (No field named versiontag) #765

What happened

Any write into a node type that has a camelCase @unique property fails on 0.11.0 with a Lance/DataFusion planner error — the uniqueness lookup sends the column name unquoted, DataFusion normalises it to lower case, and the column is not found:

storage: Invalid user input: Schema error: No field named versiontag. Column names are case sensitive.
You can use double quotes to refer to the "versiontag" column or set the
datafusion.sql_parser.enable_ident_normalization configuration. Did you mean 'versionTag'?

It fails on a fresh, empty graph with a single row, for load --mode append, load --mode merge, and a mutate … insert. load --mode overwrite succeeds (it skips the lookup). A camelCase @index (non-unique) column and a snake_case @unique column both load fine, so the fault is specifically the @unique check on a mixed-case name. Expected: the lookup quotes the identifier (or disables ident normalisation) and the row lands.

Consequence: a type with such a column is effectively write-only through overwrite. Found rebuilding a cluster whose dev graph declares Release.versionTag: String @unique; the rebuild script now loads that one type as an overwrite batch (ModernRelay/mr-cluster-aws, scripts/cluster-rebuild-org-split.sh).

Steps to reproduce

--- schema
node Release {
    slug: String @key
    versionTag: String @unique
}
node Tag {
    slug: String @key
    versionTag: String @index
}
node Plain {
    slug: String @key
    version_tag: String @unique
}

--- seed (one file per type)
{"type":"Release","id":"r1","data":{"slug":"r1","versionTag":"v0.1.0"}}
{"type":"Tag","id":"t1","data":{"slug":"t1","versionTag":"v0.1.0"}}
{"type":"Plain","id":"p1","data":{"slug":"p1","version_tag":"v0.1.0"}}

omnigraph init --schema schema.pg file://$PWD/g.omni
omnigraph load --data release.jsonl --mode append --store file://$PWD/g.omni      # FAILS: No field named versiontag
omnigraph load --data release.jsonl --mode merge  --store file://$PWD/g.omni      # FAILS: same
omnigraph load --data release.jsonl --mode overwrite --yes --store file://$PWD/g.omni   # ok: 1 entities
omnigraph load --data tag.jsonl     --mode append --store file://$PWD/g.omni      # ok (camelCase, @index only)
omnigraph load --data plain.jsonl   --mode append --store file://$PWD/g.omni      # ok (@unique, snake_case)
omnigraph mutate -e 'query m() { insert Release { slug: "r2", versionTag: "v0.2.0" } }' --store file://$PWD/g.omni --as act-test
                                                                                   # FAILS: No field named versiontag

Observed: every non-overwrite write into Release fails with the planner error above, on an empty table. Expected: the row is inserted; the uniqueness check should compare against existing rows using a quoted identifier.

Version

omnigraph 0.11.0 (release binary, omnigraph --version → omnigraph 0.11.0)

Environment

macOS (Darwin 25.5) arm64, local filesystem store. The same failure was first hit against a file:// root during a cluster rebuild; not tried through a served /load, but the mutate path fails identically so a served insert is expected to as well.

Logs / output

Error:
   0: storage: Invalid user input: Schema error: No field named versiontag. Column names are case sensitive. You can use double quotes to refer to the "versiontag" column or set the datafusion.sql_parser.enable_ident_normalization configuration. Did you mean 'versionTag'?., /Users/runner/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/lance-datafusion-11.0.0/src/planner.rs:1025:20

Location:
   crates/omnigraph-cli/src/client.rs:725