LanceDBVectorStore delete/delete_nodes/get_nodes fail on lancedb>=0.38 because double-quoted IDs now parse as identifiers

Finding: In an external report on run-llama/llama_index issue 23086, llama-index-vector-stores-lancedb 0.6.0 (also reported on main) builds delete and filter predicates with double-quoted IDs, and with lancedb 0.38.0 or later these fail with a schema error such as "No field named item1" (https://github.com/run-llama/llama_index/issues/23086). This is an external report and was not reproduced by KFA. Affected calls, per the reporter: delete(), delete_nodes(), and get_nodes() when node_ids is passed; delete_ref_doc() is said to fail for every input. The reporter's hypothesis is that lancedb PR #3825, reportedly merged 2026-08-26, changed SQL parsing so double quotes denote identifiers and single quotes denote string literals, so doc_id = "item1" now refers to a nonexistent column. The reporter says lancedb 0.38.0 is the first release with this behavior. The package declares lancedb>=0.21.1 with no upper bound, while its committed uv.lock reportedly pins 0.37.1, which would explain why the existing tests did not catch it. The reporter says bumping the lockfile alone makes test_delete, test_delete_nodes and test_get_nodes fail (https://github.com/run-llama/llama_index/issues/23086). A repro without LlamaIndex is given: create a lancedb table with a doc_id column and call delete with a double-quoted predicate (same issue URL). Proposed mitigation (not confirmed as merged or released): the author of PR #23087 says it renders IDs as single-quoted SQL literals with embedded single quotes doubled. A comment reports that the lancedb.expr approach was dropped because it does not work across the declared floor: lancedb.expr is missing in 0.21.1 to 0.30.1 and Table.delete(Expr) raises TypeError in 0.30.2 to 0.33.x. The comment says the SQL-string version passes the full suite on 0.21.1, 0.30.2, 0.33.0, 0.34.0, 0.38.0 and 0.40.0 (https://github.com/run-llama/llama_index/issues/23086#issuecomment-6075715311). These results are self-reported and not independently verified. Status: the issue is open. No maintainer confirmation of cause, no merge of #23087, and no released fix appear in the supplied content, and comment coverage may omit middle comments. The same comment says metadata filter escaping in _to_lance_filter is a separate, unaddressed problem. Pinning lancedb below 0.38 is a plausible inference but is not stated by any source.