fluree query: a from naming the target ledger's own named graph or #txn-meta is silently ignored #1972

Summary

In local mode, a JSON-LD from that names one of the target ledger's own graphs is silently ignored. Here "target ledger" means the active ledger, or the one given on the command line. The query runs against the default graph instead:

• "from": "mydb:main#<named-graph>" returns default-graph rows.
• "from": "mydb:main#txn-meta" returns nothing.
• SPARQL FROM <mydb:main#txn-meta> errors with "references a graph that is not in this ledger".

The same queries return the right answers when a different ledger is targeted. The behavior is identical on v4.2.1 and on current main.

Reproduction

fluree init
fluree create mydb
fluree upsert mydb --format turtle -e '@prefix ex: <http://example.org/> .
@prefix fluree: <https://ns.flur.ee/db#> .
ex:a ex:p "in-default" .
GRAPH <http://example.org/g> { ex:a ex:p "in-g" . }
GRAPH <#txn-meta> { fluree:commit:this ex:batch "b-1" . }'
fluree create other

G='{"from":"mydb:main#http://example.org/g","select":"?o","where":{"@id":"http://example.org/a","http://example.org/p":"?o"}}'
M='{"from":"mydb:main#txn-meta","select":"?o","where":{"@id":"?c","http://example.org/batch":"?o"}}'

fluree use mydb
fluree query "$G"      # ["in-default"]  wrong: expected ["in-g"]
fluree query "$M"      # []              wrong: expected ["b-1"]
fluree query 'SELECT ?o FROM <mydb:main#txn-meta> WHERE { ?c <http://example.org/batch> ?o }'
                       # error: SPARQL FROM/FROM NAMED references a graph that is not in this ledger

fluree use other
fluree query "$G"      # ["in-g"]  correct
fluree query "$M"      # ["b-1"]   correct

fluree query mydb "$G" with other active also returns ["in-default"]. SPARQL GRAPH <http://example.org/g> { … } against mydb returns in-g, so only the from / FROM selector is affected.

Where it goes wrong

query_targets_foreign_source (fluree-db-cli/src/commands/query.rs) decides between the connection path and the single-ledger view. It compares base_ledger_id(from) with the endpoint, and base_ledger_id drops the #graph fragment. So mydb:main#<g> counts as "same ledger", and the query runs through fluree.query(&view, …) on the ledger's default view:

• JSON-LD: the view query does not apply the from graph selector and does not reject it either.
• SPARQL: the view path's within-ledger FROM check does not recognize <ledger#txn-meta> as one of the ledger's graphs.

When a different ledger is targeted, the body counts as foreign and goes through the connection path, which resolves both fragments correctly.

The named-graph case is the worst of the three: a user who asks for a named graph gets default-graph rows with no warning.

Possible fixes

• Route a from / FROM that carries a graph fragment to the connection path.
• Or make the view query honor the selector, or refuse it with an error.

Found while documenting TriG on insert (#1971). It is unrelated to that change.