fix: typed dataset and graph references: one grammar, one resolver - #2007

A ledger, a time, a graph of a ledger and a bare graph IRI are all written
as text, and each surface split that text itself: at HEAD there are seven
parsers of the address grammar, and they disagree about '#', '@' and
'urn:fluree:'. This adds the one typed form they can all share, in a new
fluree-db-core module, dataset_ref:

- GraphIri: an absolute IRI (validate_absolute_graph_iri), the only way to
  name a graph by IRI.
- GraphSel { Default, TxnMeta, Config, Named(GraphIri) }: which graph of one
  ledger. The one keyword table for 'default' / 'txn-meta' / 'config'. A
  relative name is refused instead of being looked up literally.
- LedgerRef { id, at: Option<TimeSpec>, graph: GraphSel }, private fields:
  the parsed address for ledger positions. Replaces the raw-string struct
  of the same name (its pin was a String and its fragment unvalidated).
- DatasetRef { Address | GraphIri | Ambiguous }: what a dataset-position
  string (FROM, FROM NAMED, a JSON-LD from string) names before resolution.
  Ambiguous carries both readings of text that is lexically both, such as
  'mydb:main', for a resolver that holds a graph registry to choose.
- TimeSpec moves here from fluree-db-api (re-exported at both of its old
  paths, with From<LedgerIdTimeSpec>), together with its grammar tests.

Two grammar rules keep the address grammar from swallowing graph IRIs:

- A branch may not begin with '/': LedgerId::parse refuses one, so
  'http://ex.org/g' is no longer read as ledger 'http', branch
  '//ex.org/g'. Legacy branches that merely contain '/' still parse, and
  stored records keep parse_persisted.
- '@' starts a pin only before a known tag. In a ledger position any
  other '@' is a bad pin; in a dataset position it means the text is not an
  address ('http://ex.org/@alice/g', 'mailto:a@b').

With the first rule a hierarchical graph IRI no longer parses as an id, so the SQL and
Delta dispatch probes, which receive the GRAPH IRIs a query writes, now
classify the IRI first: one that does not parse as a graph-source id names
no source and is declined without a lookup, while a failed lookup of a
well-formed id still fails the query: the same guard #1997 added
(dispatch_record).

The existing LedgerRef callers (server path parsing, scope_id, the MCP
ledger argument, the graph-source fallback, same_ledger) move to the typed
accessors.

A dataset member was a GraphSource with an `identifier: String` that every
consumer re-read: a SPARQL FROM IRI went through its own stringifier
(prefixed names unexpanded), then a third address parser that split '@' and
'#' textually, and a graph IRI on a connection route was looked up in the
nameservice as a ledger. Members are now parsed once into typed values and
resolved by one table.

- GraphSource keeps the text as written, what it names (MemberRef: a graph
  keyword, or a DatasetRef), its time and its per-source options, behind
  private fields. It is built by parsing (GraphSource::parse, TryFrom,
  FromStr) or from a typed address (GraphSource::ledger); `identifier` is
  gone. dataset::GraphSelector is now an alias of core's GraphSel.
- One JSON-LD dataset parser: DatasetSpec::from_json reads the `opts` and
  `ledger` spellings that only from_query_json used to. An object's `@id`
  is a ledger address and its `graph` a graph of that ledger; naming a
  graph in both is refused.
- SPARQL dataset clauses are read from resolve_dataset_clause, so prefixed
  and BASE-relative FROM / FROM NAMED IRIs expand against the prologue on
  every route (DatasetSpec::from_sparql / from_sparql_ast). A dataset IRI
  written in full is taken as written: FROM <mydb:main> is not a misused
  prefix even when the query declares `mydb:`.
- core gains MemberRef and TargetLedger, the resolution table for a
  ledger-scoped surface: the ledger's own address in any spelling is its
  default graph; the written text as an exact registry IRI (reserved slots
  included) is that graph; a keyword or `L#graph` selects within; another
  ledger is CrossLedger; an unknown graph IRI is GraphNotFound. The view
  path's within-ledger FROM and every graph selection (`db("L#g")`, a
  member's graph) resolve through it, so the short alias `FROM <L>`,
  `FROM <L#iri>`, `FROM <L#config>`, a keyword, and the main branch's
  `urn:fluree:L:main#config` read from a branch all work there (#1512).
- On a connection surface a bare graph IRI or keyword names no ledger: a
  400 that names the fix, instead of a nameservice lookup of the IRI.
- A named member is known by its alias, else its text as written, pin
  included: `FROM NAMED <L@t:2>` answers `GRAPH <L@t:2>` and two pins of
  one ledger are two members. The time-stripped name it had before stays a
  non-enumerated alias while exactly one member claims it, so
  `GRAPH <L>` over one pinned member still matches (DataSetDb gains the
  alias map).
- Caller mistakes in this area are no longer 500s: an unknown graph is a
  404 (new ApiError::GraphNotFound, which is not is_not_found(), so it
  never falls back to a graph-source lookup); a missing dataset, a
  cross-ledger or pinned within-ledger member, and the within-ledger
  history-range refusal are 400s. An unknown pin tag in a dataset position
  reports the pin, not "not an IRI".
- sparql_dataset_ledger_ids returns the canonical ids a clause names by
  address (graph IRIs are not ledgers), and the CLI's "already has a
  dataset clause" guards use the new sparql_has_dataset_clause.
- Fluree::is_single_ledger_fast_path (test-only callers) is removed.

The ledger route keeps its own FROM classifier for now and only moves to
the typed constructors; routing it through TargetLedger follows.

…robed

`R2rmlProvider::has_r2rml_mapping` returned `bool`, and the api's provider
turned every nameservice error into "no mapping"; the GRAPH operator and the
fused R2RML aggregate also `.ok()`-ed `compiled_mapping`. During a
nameservice outage a GRAPH-addressed R2RML, Iceberg or SQL source therefore
read as an empty native graph, with a 200. The probe now returns
`QueryResult<bool>`. An IRI that is no graph-source id is still `Ok(false)`
without a lookup; a lookup that fails fails the query, and so does a failed
mapping load for a graph found to be a source.

Failing closed alone would have made every query that carries the R2RML
provider (every `query_from()` and `graph().query()` on an iceberg build)
depend on the graph-source registry, because the executor probed the primary
snapshot and each dataset member on every query. Views now say what they
read: a `MemberKind` (`Native`, `GraphSource`, or `Unclassified` for callers
that do not say) on each runtime `GraphRef`, and on `ContextConfig` for the
no-dataset primary. The executor's precomputed set, the GRAPH operator, the
fused aggregate and the SQL lane never ask about a graph loaded as a ledger
graph. Graph-source members are probed as before, and a GRAPH IRI that is
not a member is the one remaining run-time probe.

A probe failure surfaces as the provider's existing "Nameservice error"
(`QueryError::Internal`, which the api maps to 400 like the provider's other
nameservice errors).

Test: it_sql_pushdown_lane `graph_source_probes_fail_closed_and_skip_ledger_graphs`
runs against real SQL sources with every graph-source lookup failing:
`GRAPH <source>` errors on and off the lane, in SPARQL and JSON-LD; the
native twin answers exactly as with a healthy nameservice through its own
view, `FROM`, and `FROM NAMED` + `GRAPH`; a GRAPH IRI that is no id answers
without a lookup.

… ledger's from

`graph()` stored the raw string and handed it to the ledger loader, which
takes only `name[:branch]`, so `graph("L#txn-meta")`, `graph("L#<graph IRI>")`
and `graph("urn:fluree:L")` failed although `db()` accepted them (#1961).
The handle now parses a `LedgerRef` once. Queries and `load()` read the
address's graph through the loader `db()` uses. A pin in the address
(`L@t:5`) is honored, and one that disagrees with `graph_at`'s is a 400;
`db()` honors a pin the same way. A transaction applies to the whole ledger
at HEAD, so `.transact()` through a graph-qualified or pinned handle is
refused with a 400. The commit builder reads the address's ledger.

A JSON-LD query on a view reads the view's ledger, but a `from` or
`fromNamed` naming another ledger, or one that does not exist, was ignored
and the query silently answered from the view. All four view entry points
refuse it now with a 400 that points at `query_from()`. A `from` naming the
view's own ledger, in any spelling, still answers. The other within-ledger
JSON-LD `from` shapes keep their current reading; honoring them on the view
path belongs to lane consolidation (part 2).

The tracked view paths report the within-ledger FROM resolver's own status
(404 for a graph the ledger lacks), as the untracked paths already do.

Tests: it_named_graphs `graph_handles_take_the_addresses_db_takes` and
`a_missing_ledger_reads_as_not_found_at_every_entry_point`; it_query_dataset
`a_view_refuses_a_jsonld_from_naming_another_ledger`.

…edger

`SERVICE <fluree:ledger:X>` looked X up among the dataset's members and,
when X was not one, ran the block against the current dataset. An endpoint
naming another ledger, or no ledger at all, therefore answered with this
dataset's rows. A non-member endpoint is now a 400 that points at
FROM NAMED, and it contributes no rows under SILENT. It is never loaded on
the spot, because a SERVICE endpoint is not authorized the way a dataset
member is. With no dataset, the endpoint must still name the query's own
ledger, as before.

The endpoint's address is parsed with the shared ledger grammar, so the
`urn:fluree:` spelling works. A pin or a graph in it is malformed: the
member's time and graphs come from the dataset.

Tests: service unit tests for the endpoint grammar; it_service_cross_ledger_iri
`service_to_a_non_member_is_refused_not_answered_by_the_dataset` and
`a_service_endpoint_is_never_loaded` (a recording nameservice sees no lookup
of the endpoint's ledger).

A single `USING <g>` or `WITH <g>`, or a JSON-LD update `from` / `graph`,
that the graph registry did not resolve fell back to g_id 0, so the WHERE
read the ledger's real default graph. `DELETE { ?s ex:v ?o } USING <typo>
WHERE { ?s ex:v ?o }` deleted it, `WITH <new> INSERT … WHERE …` copied it,
and `USING <L#config>` read the default graph instead of the config graph.
Two or more `USING` graphs skipped an unresolved IRI, which dropped
the ledger's own address. JSON-LD refused `"from": "L:main"` as an
undefined prefix.

Every WHERE-dataset reference (`USING`, `USING NAMED`, `WITH`, and the
JSON-LD `from`, `fromNamed` and `graph` keys) now resolves once, in the
transaction's ledger, through the table a query's FROM uses:
- the ledger's own address, in any spelling, names its default graph;
- `L#config` or its URN names the config graph;
- a registered IRI names its graph.
A graph the ledger does not have contributes nothing, so a WHERE over it
binds nothing (SPARQL 1.1 Update §3.1.3, Query §13.2). Another ledger's
address, or a pinned address, is a 400, since the WHERE reads only this
ledger as it stands. The single and multi branches share the resolver. The
JSON-LD dataset keys are dataset references: a prefix the context defines
still expands, and any other text is kept as written for the resolver.

#1997 resolved an update's `USING` / `WITH` default graph by a narrower
rule (own address, else registry, else empty). This is its generalization;
the rebase onto #1997 keeps this side.

Test: it_named_graphs
`update_where_dataset_references_resolve_in_the_transactions_ledger`, each
shape above in SPARQL and JSON-LD, with the cross-ledger and pinned
refusals.

…dger

The ledger routes (`/query/{L}`, `/stream/query/{L}`, `/explain/{L}`) loaded,
authorized and compared the path as spelled, so `/query/b2x` with
`FROM <b2x:main>` or `"from": "b2x:main"` was a ledger mismatch, and
`/query/urn:fluree:b2x:main` could not load at all (#1982). `PathLedger` now
carries the canonical id (plus any graph the path selects), and every
downstream use reads it.

Each SPARQL `FROM` / `FROM NAMED` IRI, and each JSON-LD `from` / `fromNamed`
source, was classified by string shape: an IRI with `#` or `@` was taken for
ledger syntax ("Ledger mismatch" for `<http://ex.org/vocab#products>`,
"Invalid time travel" for `<http://ex.org/@alice/g>`), the short
alias or the URN of the path's own ledger read as a graph name (500 Unknown
named graph), and a graph IRI in `fromNamed` was loaded as a
ledger (404). The clause is now expanded against the prologue first
(prefixed and BASE-relative IRIs), and each reference resolves once, in
the path's ledger, through the table the view path and updates use, with the
ledger's graph registry:
- the ledger's own address in any spelling names it, or the graph the
  address names;
- a keyword or a registered IRI names that graph;
- an IRI the registry does not hold is left to loading, which answers 404
  `err:db/GraphNotFound`;
- another ledger is a 400.
A single JSON-LD `from` must name the path's ledger. A `from` array and
`fromNamed` may also name other ledgers, as before. The dataset lane and its
per-member loading are unchanged.

`ApiError::GraphNotFound` now maps to 404 with the new `@type`
`err:db/GraphNotFound` on the server (it fell through to a 500).

Tests: sparql_dataset_semantics
`ledger_route_dataset_references_resolve_in_the_paths_ledger` (graph IRIs
with `#` and `@`, the config graph by its URN, each spelling of the path and
of the ledger in `FROM` and `from`, a prefixed `FROM NAMED`, a graph IRI in
`fromNamed`, an unknown graph, another ledger in each language); unit tests for the path id and the JSON-LD
normalization.

`fluree query` chose between the target's own view and the connection path
by comparing base names (`mydb:feature-x` and `mydb` share `mydb`) and by
reading only a string or string-array JSON-LD `from` (#1972). A branch other
than the target's ran against the target's branch; a JSON-LD `from` naming
one of the ledger's graphs, in string or object form, or naming a ledger
that does not exist, ran on the view path, which ignored it and answered
from the default graph; SPARQL `FROM` of another branch failed there.

The router now resolves each reference in the target ledger through the
table every surface shares, using the ledger's graph registry when it is
local. Locally:
- the view path keeps what it reads: its own ledger in any spelling, and
  SPARQL graphs of that ledger;
- another ledger or branch, a time pin, and every JSON-LD source other than
  the whole ledger (a graph, `fromNamed`, a history `to`) take the connection
  path, which reads them.
For a remote target, the ledger route resolves references against its own
registry, so only a reference that names another ledger leaves it. The base
name comparison and the `from` scraper are gone.

Tests: unit routing decisions for the local and remote rules; CLI
integration `local_query_reads_the_graph_or_branch_its_dataset_names`
(graph by address and object form, config graph, another branch in JSON-LD
and SPARQL, a missing ledger).

Callers outside db read which ledgers a query names before running it,
through `DatasetSpec::from_query_json` (each member's `identifier` and
`policy_override`) and `sparql_dataset_ledger_ids`, so these two must report
every ledger the query can read. The typed members had made `identifier` and
`policy_override` private and changed what `sparql_dataset_ledger_ids`
reported.

Both fields are public again. `identifier` is the reference as the query
named it, with an address's `@` pin removed and a `#graph` kept, as before.
Both are derived from the typed parse, and resolution reads the typed
reference, never them. `sparql_dataset_ledger_ids` reports every member's
identifier (minus `#graph`) and the history range's ledger, as before. A
reference whose reading depends on a ledger's graph registry is reported
too.
The typed ids the connection path loads are the new `sparql_dataset_ledgers`,
which the server's own authorization, refresh and comparisons now use.

A dataset clause's prefixed name whose prefix is not declared
(`FROM ledger:main`) is again the ledger address as written; a declared
prefix still expands.

Tests: dataset unit tests `from_query_json_reports_every_named_ledger` and
`sparql_dataset_ledger_ids_reports_every_named_ledger` (string, array and
object `from`, `{"@id", "t"}`, `fromNamed` object, legacy `from-named`,
`opts.from`, `ledger`, `FROM<x>` with no space, a bare `FROM ledger:main`,
several clauses, a commented-out clause, a history range, a per-source
policy); it_query_dataset
`reported_dataset_ledgers_cover_every_ledger_the_engine_reads`, which runs a
corpus through a recording nameservice and checks that every ledger whose
record the engine reads was reported. The recording nameservice moves to
the shared test support.

A dataset that names only named graphs has an empty default graph (SPARQL
1.1 §13.2), so patterns outside `GRAPH` match nothing. HTTP says so in an
`x-fdb-warning` header computed by two route-level walkers, one per
language, which do not look inside `EXISTS`. Embedders and the CLI were
told nothing.

`QueryAdvisory` (for now `EmptyDefaultGraph`) is computed once in the API
from the resolved dataset and the lowered query. One IR walker serves both
languages and reaches `OPTIONAL`, `UNION`, `MINUS`, sub-queries and `EXISTS`
/ `NOT EXISTS`. It is carried on `QueryResult::advisories` (an additive
field), and `query_from()` can return it alongside a formatted result
(`execute_formatted_with_advisories`). The CLI prints each advisory to
stderr on the view and connection paths; rows are unchanged. The HTTP header
keeps its route-level walkers for now.

Tests: it_query_dataset
`a_named_only_dataset_advises_when_the_query_reads_its_empty_default_graph`
(SPARQL and JSON-LD, a pattern only inside `FILTER EXISTS`, `GRAPH`-only
and default-graph controls); CLI integration
`a_named_only_dataset_warns_on_stderr`.

`fluree query --remote … --at` carried the time inside the query. For
SPARQL it injected `FROM <ledger@t:N>`, which left a `GRAPH` block nothing
to match (the dataset then has no named graphs) and refused a query that
had its own FROM / FROM NAMED. For JSON-LD it overwrote `from` with
`<ledger>@t:N`, so a `from` naming a graph or another member was lost.

The server's ledger routes have taken a pinned path
(`/query/<ledger>@t:N`, `/explain/<ledger>@t:N`) since v4.2.2. The CLI now
posts the query as written to the pinned path, so a query with no dataset
clause reads the ledger at that time, named graphs included, and a query's
own dataset keeps what it names and is read at that time.

A server that predates path pins parses the whole path as a ledger id and
refuses it: v4.1.6 and v4.2.1 both answer a 500, "Invalid ledger ID format
'<ledger>@t:N': expected 'name' or 'name:branch'" (run against both
binaries). On an "invalid ledger id" error that names the pinned path, and
only then, the CLI falls back to the older rewrite. So does an alias that
names a graph, because a pin cannot ride with a `#graph` in the path.
NDJSON and TSV/CSV output keep the older form until lane consolidation
(part 2).

Tests: CLI unit `remote_at_pins_the_ledger_path` and
`only_a_server_without_path_pins_falls_back` (v4.2.1's reply verbatim, and
the errors that must not fall back); server_memory
`remote_at_pins_the_path_and_keeps_the_querys_dataset` (no dataset, a
`GRAPH` with no dataset clause, a JSON-LD `from` naming a graph, and SPARQL
FROM NAMED, each at t=1 of two commits) and
`remote_at_falls_back_on_a_server_without_path_pins` (a stand-in that
replies as v4.2.1 does: the pinned request, then the older rewrite on the
unpinned path).

…dataset position)

`LedgerRef` had a private parse mode, `UnknownPin::NotAnAddress`, that
answered "not an address" for an `@` whose tag is not a known one, and
`DatasetRef::parse` used it. `DatasetRef::parse` also falls back to the IRI
reading for any text that fails the address grammar, and an unknown tag
always fails it (the pin parser accepts only the known tags), so the mode
never changed an answer. It is gone. `LedgerRef::parse` is the one address
parser (an unknown tag is a malformed pin there), and `DatasetRef::parse`
states the rule where it applies it. No behavior change; the unit tests for
the rule are unchanged.

…r surface

- CLI `issue_1972_reproduction_reads_the_graph_each_from_names`: #1972's
  commands as filed (a JSON-LD `from` naming a graph and `#txn-meta`, and
  SPARQL `FROM <mydb:main#txn-meta>`, with the ledger active and with
  another ledger active).
- CLI `issue_1512_sparql_from_reads_the_config_graph`: SPARQL
  `FROM <ledger#config>` in every spelling of the address, and the keyword.
- api `a_branch_reads_config_by_the_main_urn_and_urn_named_graphs_stay_graphs`:
  a branch reads its config graph by the main branch's URN, which it
  inherited, by its own URN and by keyword, and a user graph named
  `urn:fluree:…#…` stays a graph; SPARQL `FROM` and `FROM NAMED` + `GRAPH`
  on the branch's view, and the JSON-LD `from` object through
  `query_from()`. The resolver's unit tests held this with a hand-built
  registry; this runs it against a real branch.
- api `solo_jsonld_dataset_shapes_still_answer`: the JSON-LD dataset shapes
  solo sends (a pinned object reading `txn-meta` by `t` and by `at`, an
  object naming a user graph, the bare and branch-qualified ledger, and a
  history range) answer through `query_from()`.
- api `the_embedder_surface_on_the_hard_keep_list_still_compiles`: the
  multi-query struct literals, the agent-JSON context fields, the paths and
  streaming entry points embedders use, the SPARQL dataset clause, the
  time-travel split and conversion, and the dataset parsers an authorizer
  reads, named the way an embedder names them.

The pages that described behavior this branch changes, or documented a
form that did not work:

- query/sparql.md: a SERVICE endpoint must be a dataset member (or the
  query's own ledger), takes no pin or graph, is never loaded on its own,
  and contributes no rows under SILENT; the `urn:fluree:` endpoint
  spelling; SPARQL comments in the examples. `USING` / `WITH` resolve in
  the ledger being updated.
- transactions/update-where-delete-insert.md: the JSON-LD `from` /
  `fromNamed` twin of that.
- guides/cookbook-branching.md: the branch-diff example names both branches
  in its dataset, as SERVICE now requires.
- ledger-config/README.md: `FROM <config>` names the config graph where a
  query targets one ledger (the page said it was refused).
- concepts/datasets-and-named-graphs.md: on the connection endpoint a graph
  is named with its ledger (a bare graph IRI is a 400); the ledger-scoped
  keywords and address spellings; three examples put FROM NAMED before
  SELECT.
- reference/graph-identities.md: full `https://` IRIs and a BASE do not
  name a ledger (never implemented); a BASE-relative dataset IRI expands to
  a graph IRI, and the `urn:fluree:` form is how to name a ledger under a
  BASE.
- api/errors.md: `err:db/GraphNotFound` (404) and the 400s for another
  ledger or a malformed reference.
- cli/server-integration.md, guides/cookbook-time-travel.md: `--remote
  --at` uses the pinned ledger path, with the fallback; where a SPARQL
  `FROM` pin works.
- indexing-and-search/geospatial.md: `@t:100`, not `?t=100`.
- graph-sources/overview.md: SPARQL comments.

The "SPARQL Execution Modes" section of query/datasets.md (#1975) waits for
lane consolidation (part 2).

One function now reads a JSON-LD query's dataset in the ledger a surface
addresses, and the server and the CLI both route by it:

- `resolve_jsonld_dataset_in_target` rewrites the body so each source names
  what the target ledger reads for it: a graph of the ledger (by keyword,
  registered IRI or `L#<g>`) becomes `{"@id": <ledger>, "graph": <g>}`, the
  ledger's own address in any spelling stays as written, and another ledger
  is refused in a lone `from` on a ledger route or left for the dataset lane.
  It reports the lane the rewritten query runs on and whether it names
  another ledger.
- `jsonld_lane`, `jsonld_view_ledger`, `jsonld_dataset_ledger` and
  `jsonld_names_dataset` read the dataset keys with the precedence of
  `DatasetSpec::from_json` (`opts` before the top level, `from` before
  `ledger`, `fromNamed` before `from-named`). A lone `from` runs on a view
  only when it names a whole ledger at head.
- Graph IRIs resolve through a borrowed lookup into the ledger's cached head
  (`LedgerView::graph_id_for_iri`). The server's `ScopeRegistry` and the
  CLI's endpoint registry no longer copy the registry per request.
  They read the head with `LedgerHandle::peek`, which skips the read-side
  compaction check `snapshot` runs. That check visits every graph in
  novelty, and the query's own load runs it anyway: a second one per
  request cost 6-8% CPU on a ledger with 20,000 named graphs (server CPU
  per ledger-route request with `FROM` + `FROM NAMED`, debug build: 2.82 ms
  on the base, 3.20 ms with the second check, 2.83 ms peeking).

Server: the ledger routes' `normalize_ledger_scoped_from`, the view/lane
choice (`requires_dataset_features`) and `get_ledger_id` delegate to these.
A body whose dataset sits in `opts` is now read where the parser reads it:
`{"opts": {"from": "a:main"}}` on `/query` runs on `a:main` instead of
failing with a missing ledger, and an `opts.from` naming another ledger on a
ledger route is a 400 however the top level reads.

The server test `dataset_options_and_envelope_defaults_cannot_replace_authority`
sends `{"from": L, "opts": {"from": {"@id": other}}}` with a token for L
only. The connection route still answers 404 (`other` is outside the token,
as if it did not exist). The ledger route now refuses it as the lone `from`
naming another ledger, a 400 that says no more than the request did, where
it used to read the top-level `from` and leave `other` to the token check.

CLI: the router resolves the body with the same function. A local query
whose dataset leaves the view is sent to the connection path with the body
its ledger resolved, so `"from": "config"` or a registered graph IRI reaches
the connection path named as that ledger's graph.

A JSON-LD query on a view read its dataset keys only to refuse another
ledger. Anything else a dataset can say was ignored and answered from the
view: a time pin, a graph of the view's own ledger (by address, keyword or
object), named graphs, a history range, or a dataset that does not parse.

The view now reads the dataset as `DatasetSpec::from_json` does (`opts`
first) and accepts only the ledger's own address, in any spelling, as a
default graph with nothing of its own beside the address. Everything else is
a 400 that points at `query_from()`. Every view entry point applies it:
buffered and tracked, with and without the graph-source providers, and the
streaming planner.

The connection path's one-ledger shortcut and a single-ledger dataset hand
a view that already holds the query's dataset (loaded at the member's time
and graph) to the same entry points; they mark the execution options so the
view does not read the dataset keys a second time.

… 500

A graph-source probe or lookup whose nameservice call failed was reported
as `QueryError::Internal`, which the API and the server map to 400 with every
other query error. A backend outage then read as a caller mistake: clients
did not retry it and monitoring counted it as bad requests.

`QueryError::Nameservice` now carries these failures from every graph-source
site (the R2RML provider's probe, mapping, table and SQL lookups). The API
maps it to 500, and the server types it as the nameservice error it is
(`errors::NAMESERVICE`, 500), both ahead of the generic query arm.

Tests: the fail-closed lane tests assert the 500. `a_failed_source_lookup_
still_fails_the_query` now asks about a `GRAPH` IRI on the ledger's view,
where the probe still runs (a dataset member's `GRAPH` is never probed), and
the graph-source lane test no longer pins what an undeclared graph source
answers through `GRAPH` on a plain view; it keeps the fail-closed cases.

…ling

`GraphSource::identifier` (what `DatasetSpec::from_query_json` reports) and
`sparql_dataset_ledger_ids` reported an address as written minus its pin, so
`urn:fluree:g:main` came back with its `urn:fluree:` wrapper. A consumer that
authorizes the reported ledgers compares `name[:branch]` strings, and a
wrapped one matched nothing.

An address is now reported as `name[:branch][#graph]` regardless of
spelling: the `urn:fluree:` wrapper and the `@` pin are removed, and a bare
name stays bare (it is not rewritten to `name:main`). Anything that is not
an address is still reported as written.

`reported_dataset_ledgers_cover_every_ledger_the_engine_reads` no longer
canonicalizes the reported side. It reads each reported string as a
consumer does (dropping `#graph` and `@pin`, keeping the branch, a bare name
standing for its `main` branch) and checks that it covers every ledger the
engine read. Its corpus now also covers `opts` over the top level, named
objects, a sub-query's own dataset keys, and SERVICE, nested or not.

…ne time

core: `DatasetRef::parse` read `urn:fluree:L:main@t:abc` as a graph IRI, so
the malformed pin surfaced as a graph that does not exist, while the same
address without `urn:fluree:` reported the pin. Both spellings now report
it. An address with nothing after its `#` (`dsx:main#`, `urn:fluree:dsx:main#`)
is likewise the address's error, a 400, instead of a graph IRI with an
empty fragment; an IRI that is no address keeps its empty fragment
(`http://ex.org/ns#`).

query: a SERVICE naming a ledger read whichever of that ledger's members it
found first, and named members sit in a map with no order, so a dataset
holding the ledger at two times (two pins are two members) answered from
either. `DataSet::service_member` picks the first default graph, else the
named member first by name, and refuses a ledger the dataset holds at more
than one time (400, or no rows under SILENT).

…one way

This picks up the rest of the review comment on #1997
(#1997 (comment)). #1997 made
the ledger's own address name its default graph in an update's
default-graph positions (SPARQL `WITH`, a JSON-LD top-level `graph`); every
other graph position still read it as a graph IRI, so a template, a data
quad or a TriG block named by the address created a graph under it, and a
`GRAPH ?g` bound to it through `USING NAMED` read the default graph but
wrote such a graph.

One table now answers what an IRI names in a graph position of a ledger
(`TargetLedger::graph_position`), for reads and writes alike:

- the ledger's own address, in any spelling: its default graph;
- the address with an IRI graph (`L#<g>`): the graph `<g>`, created by a
  write when the ledger does not have it;
- any other IRI: the graph registered under it exactly, or none (a write
  creates it).

No write creates a graph under an address of this ledger: `L#<L>` with no
such graph and the address with a time are refused as write targets. A
reserved graph keeps the IRIs it is registered under. Only an IRI that starts
with the ledger's name is parsed; any other costs one registry lookup.

Where it applies:

- transact: every template graph, `Txn::write_graphs` (`CREATE GRAPH`
  included) and a sync target resolve through the table before staging, and
  each `GRAPH ?g` binding through the same table as the WHERE streams, so a
  `?g` template writes the graph its WHERE read. The template-default special
  case #1997 added (`Txn::template_default_graph`,
  `TripleTemplate::graph_from_template_default`) is removed: it is a case of
  the table. Graph management keeps registry semantics for the graphs it
  names but does not create one under the address.
- import: a bulk-import TriG block named by the address loads into the
  default graph, and `L#<g>` into `<g>`.
- The update's WHERE with no `USING` reads `GRAPH <iri>` through the table
  (a `DataSet` name resolver, one lookup per name the dataset holds no key
  for), and a single-ledger query's `GRAPH <iri>` and `GRAPH ?g` do the same.
  A graph registered under the address before this change is listed by
  `GRAPH ?g` as `L#<address>` on both sides, which reads it back.
- JSON-LD: a top-level `graph`, a `["graph", …]` template or a node `@graph`
  spelled as a ledger address that strict compact-IRI expansion refuses
  (`mydb:main` with no `mydb` prefix) is kept as written, as `from` is, and
  staging accepts it only as an address of the ledger it writes.

One contract for what a graph position reads and writes for the ledger's
address, in concepts/datasets-and-named-graphs.md, which the SPARQL and
JSON-LD update pages now point to instead of stating their own. It picks up
the rest of the review comment on #1997
(#1997 (comment)): the address
in any spelling is the default graph in every graph position, `L#<g>` is the
graph `<g>`, no write creates a graph under the address, a `GRAPH ?g`
template writes the graph its WHERE read, and a graph an earlier version
registered under the address is reached, and listed, as `L#L`, with the
graph-management recipe that moves it into the default graph.

sparql.md drops the paragraph that limited the address to `USING` and `WITH`
(it contradicted the one after it), and says the same of `GRAPH <iri>`,
templates and data quads. The connection route's refusal is worded as it
behaves: a keyword, or an IRI that cannot be a ledger address, names no
ledger; an IRI that could be one is looked up as a ledger.

…d graph

A graph position read the ledger's own address with a reserved keyword
(`L#config`, `L#txn-meta`) as a plain IRI, so a write named that way created
a user graph called by that text: a data quad, a template `GRAPH`, `WITH`,
`CREATE GRAPH`, and the JSON-LD forms. The same graph's `urn:fluree:` name
wrote the config graph, and a write to `urn:fluree:L:main#txn-meta` was
refused.

The address with a reserved keyword, in any spelling and with no time, now
names that reserved graph in every position, reads and writes alike, as its
`urn:fluree:` form does (`TargetLedger::reserved_graph_iri`):
- a graph position writes the config graph, and a `#txn-meta` write meets
  the existing reserved-graph refusal;
- a dataset position reads it first, as it reads the address alone, before
  the exact-registry step; a graph an earlier version registered under the
  literal text is reached, and listed by `GRAPH ?g`, as `L#<text>`;
- CLEAR, DROP, ADD, COPY and MOVE refuse it as they refuse the
  `urn:fluree:` form.

Docs: the graph-position table and the SPARQL update page.

Tests: core `an_address_with_a_reserved_keyword_names_the_reserved_graph`;
it_named_graphs `test_an_address_with_a_reserved_keyword_names_the_reserved_graph`
(each write position in both languages, the txn-meta and graph-management
refusals, WHERE and FROM reads) and
`test_a_graph_registered_under_a_reserved_keyword_address_is_reached_through_it`;
server `ledger_route_reserved_keyword_addresses_name_the_reserved_graphs`;
CLI `local_reserved_keyword_addresses_name_the_reserved_graphs`.

CLEAR, DROP, ADD, COPY and MOVE named graphs by their exact registry IRI, so
a graph named through the ledger's address was out of their reach. With a
graph an earlier version registered under `L#config`, `ADD`, `COPY` or
`MOVE GRAPH <L#L#config>` reported that the source does not exist, and
`DROP GRAPH <L#L#config>` succeeded without dropping anything.

They now read `L#<g>` as the graph `<g>`, as every other update position
does, and the address with a reserved keyword as that reserved graph, which
they refuse (`TargetLedger::graph_management_iri`). The address itself
(`L`, `L#default`) keeps registry semantics: `DROP GRAPH <L>` is the graph
registered under `L`, never the default graph.

Docs: the graph-position page and the SPARQL page.

Test: it_named_graphs
`test_graph_management_reads_a_graph_named_through_the_address`: for a graph
registered under `L#config` and for one under `L#txn-meta`, ADD, COPY, MOVE
(from it, and back into it as the destination) and DROP through
`L#L#<keyword>` act on that graph; a plain graph is reached through
`L#<g>`; `DROP GRAPH <L>` acts on the graph registered under the address
and leaves the default graph untouched. Core unit assertions for
`graph_management_iri`.

…ames

To resolve a request's dataset references, the ledger route and the CLI
router built a whole `LedgerView` of the cached head, copying its
nameservice record's strings, and boxed it, for one lookup per reference.

`LedgerHandle::graph_names` returns only what that lookup reads, the
snapshot's graph registry and the binary index store's, as two shared
handles (`GraphNames`). `LedgerView::graph_id_for_iri` and
`GraphNames::graph_id_for_iri` share one lookup, in the order every read
path uses. `LedgerHandle::peek`, which this branch added for the route and
the CLI, is gone, and `LedgerHandle::snapshot` is as it was on main.

Per request, in-process: 3 fewer allocations on the dataset_http w1, w2 and
c shapes.

A `GraphSource` kept its text twice, as written and as its identifier,
though the two are the same text unless the member is spelled
`urn:fluree:…` or with a pin, or given as an object's `@id`. It now keeps
the identifier, and the text as written only where the two differ;
`written()` and `name()` read the same text as before.

`GraphSource::ledger` builds `name:branch[#graph]` once, at its final
length: it was formatted, regrown twice and copied into a new allocation.
`GraphSel::as_str` gives a graph's text for both it and `Display`.

The public `identifier` field is unchanged; it is derived from the parse, to
be read, not set.

Per request, in-process: 3 fewer allocations and 2 fewer reallocations on
the dataset_http w1 and c shapes, 1 fewer allocation on w2.

Test: dataset `a_member_keeps_its_text_once_unless_it_differs_from_its_identifier`
(the written text is the identifier's own storage for an address
`GraphSource::ledger` builds, a canonical address, a graph IRI and a keyword,
and separate for a `urn:fluree:` or pinned spelling).

… copying IRIs

`TargetLedger::graph_position` copied every IRI it read into a new
`Arc<str>`, and a single-ledger `GRAPH <iri>` reads one up to seven times
per request (`single_db_user_graph_id` and its neighbours), dropping each
copy. `GraphPosition` now borrows the text it was asked about, the whole
text or the `<g>` of `L#<g>`; only a reserved graph's `urn:fluree:` IRI,
which the text does not contain, is owned. A write takes ownership where it
records the graph (`WriteGraph::Named`), as it did before.

Resolving a member copied its IRI again when the registry held it
(`TargetLedger::resolve` and `TargetLedger::graph`); it now shares the
member's own `GraphIri`.

Per request, in-process: 7 fewer allocations on the dataset_http d shape, 2
fewer on w1, w2 and c.

Test: dataset_ref `graph_positions_and_resolved_graphs_copy_no_iri` (a
position's IRI is the caller's own text, the `<g>` of `L#<g>` included, and
a resolved or selected graph shares the member's `GraphIri`).