query run --from with a nested path silently returns [] instead of erroring

Start in apps/datatugapp/commands/cmd_query.go and inspect buildQuery, especially how --from is passed to dal.NewRootCollectionRef. Reproduce the command with a nested path against an OpenVaultDB source, then make the command report a clear root-collections-only error instead of returning []. Confirm that valid root collection queries retain their existing behavior.

query run --from with a nested path (e.g. lists/to-buy/items) against an OpenVaultDB source silently returns [] instead of erroring, indistinguishable from "this collection is genuinely empty."

Evidence

Verified 2026-09-17 against datatug-cli main @ 866b6b0 and openvaultdb/ovdb main @ 40d3237, with a real OVDB local server serving the built-in TODO demo (two lists, to-buy and to-watch, each with items).

datatug query run --db "openvaultdb://<home>/explore/datatug/todo.json" \
  --from lists/to-buy/items --as local-owner --no-policies --format json

Output: exit 0, [] — indistinguishable from "this collection is genuinely empty."

A raw curl -X POST /v1/databases/todo/dtql with from: {name: "lists/to-buy/items"} confirms the server (openvaultdb-go, root-collections-only) returns {"records":[]} with HTTP 200, not an error, for an unknown collection name. On the client side, --from's value is passed straight to dal.NewRootCollectionRef(o.from, "") in cmd_query.go's buildQuery — the string "lists/to-buy/items" is sent to the server as one literal root-collection name, not a path, so it can never match anything even if the collection genuinely has records elsewhere.

Suggested fix

buildQuery (apps/datatugapp/commands/cmd_query.go) could reject a --from value containing / up front with a clear "root collections only" message (or a "not found" style error), rather than silently returning an empty result that looks identical to a genuinely-empty collection.

The real fix for reaching nested collections is upstream in openvaultdb-go's DTQL (root-collections-only today) — that's tracked separately as a follow-up in openvaultdb/openvaultdb's explore-data-handoff feature spec, "External dependencies" table. This issue is only about datatug-cli's silent-empty-vs-error UX for the case as it stands today.

Where this was found

openvaultdb/ovdb's Explore data feature (hand-off from OVDB to DataTug CLI/DataTug.app), spike S4, and increment 7's implementation. Full spike notes: https://github.com/openvaultdb/openvaultdb/blob/main/spec/features/explore-data-handoff/README.md