fix: JSON-LD graph scoping, config integrity and explicit-only SHACL - #2009

graph_shape::classify_graph_value decides what a node's @graph value is:
a graph selector (a string, a bare {"@id"} object, or a one-element
array of either), JSON-LD 1.1 named-graph content (node objects), or
invalid (numbers, booleans, null, value objects, nested arrays).
doc_shape classifies a top-level object as an envelope, a named graph or
a node from the same answer, and is_graph_key recognizes @graph, a
context alias of it, and the legacy bare `graph` key only when the
context does not define `graph` as a term.

The expander adopts both: a context term `graph` is now an ordinary
property at every level instead of being hijacked as @graph (the triple
was dropped and the node re-routed), and a top-level @graph is an
envelope only when it holds node objects and the object has no @id; a
top-level graph selector expands as a node.

A JSON-LD node's statements, and those of every node nested in it, now
land in the node's scope: its own graph selector if it has one, else the
enclosing node's. Before, only a node's own triples followed its
"@graph" selector; nested nodes, anonymous nodes and @list items fell back
to the default graph (or the update's "graph" key), so the nested config
groups of #1979 landed in the default graph, a delete or upsert of a nested
node under a selector retracted in the wrong graph, and list members'
properties split from their list.

- GraphScope (ir.rs) is passed down the recursion by reference; every
  value/list/node function takes one, so a nested node cannot be emitted
  without a scope. WriteGraphs::scope is the only way to get a named
  scope, so every graph a template names is registered as a write target.
  The ambient TemplateParseCtx::default_graph and its save/restore are
  gone.
- One graph-name resolver for node selectors, ["graph", g, ...] items and
  the update "graph" key: a variable (update templates only) is the WHERE
  binding (TemplateGraph::Var, as SPARQL GRAPH ?g), a fromNamed alias its
  IRI, then the keyword table (dataset_ref::GraphSel, new in
  fluree-db-core): "default" is the default graph everywhere, "config" the
  ledger's config graph, "txn-meta" is refused; anything else expands
  @id-style and must be an absolute IRI. A variable graph used to write a
  graph literally named "?g"; "default" meant a graph named "default"
  outside the update key; relative names minted relative-IRI graphs.
- Graph insert / sync parse with the request's graph as the fixed root
  scope instead of re-homing templates afterwards; a selector naming any
  other graph is refused.
- parse_transaction / parse_graph_insert / parse_sync_transaction take the
  target ledger id (for the "config" keyword).

The #1979 recipe from docs/ledger-config/writing-config.md, verbatim:
all four statements land in #config and the configured SHACL refuses
the forbidden record. Nested @id, anonymous and @list-item nodes land in
the selector's graph (P1, P10'); a node selector beats the update graph
key for its subtree (P7c); delete and upsert of a nested node act in its
graph (P7e, P9); a variable graph writes the WHERE-bound graph; the
"config" keyword writes #config. Each compares against the SPARQL
spelling of the same write where one exists.

Renames it_config_graph::config_write_json_ld to
config_write_trig_iri_groups: its body writes TriG.

A node object with @graph content, {"@id": G, "@graph": [nodes]}, is a
JSON-LD 1.1 named graph (section 4.9): the content nodes are written to G
and the node's own properties stay in the enclosing scope. Named graphs
nest (innermost wins) and may appear as property values. Before, the
content was dropped and the first content node's @id was read as the
node's graph selector; a property-bearing object @graph lost its data the
same way.

- A named graph needs an IRI name: a blank-node or variable name, or a
  graph object without @id below the top level, is refused.
- Graph insert / sync refuse named-graph objects (the request names the
  graph). {"@id": G, "@graph": []} is no longer mistaken for the
  explicitly empty envelope a sync may clear a graph with.
- txn-meta extraction and the reserved-key strip use doc_shape: only an
  envelope's top-level keys are metadata. A single node carrying a graph
  selector (P10e) and a named graph's own keys are data; they used to be
  written as data and also as txn-meta on the commit.
- doc_shape and the expander: at the top level, an array @graph without
  @id is an envelope even when it holds one bare {"@id"} node, as every
  reader has always treated it; a single property-bearing object @graph
  is an envelope too (the single-node write form some clients send).

Anonymous nodes are labelled _:b0, _:b1, ... by one issuer for the whole
transaction body. The counter used to restart for every expansion call,
so the anonymous nodes of different ["graph", g, ...] items (and of the
plain items after them) all became _:b0 and merged into one node.

A user-written label of the issuer's own form (_:b3) would merge with the
anonymous node given that number. The parse notes such labels (templates
and VALUES), and when one was also issued it parses the document once
more with the issuer skipping those numbers. The positional labels are
part of a stored blank node's identity under upsert and sync, so their
spelling is unchanged; only documents that were being corrupted get
different labels.

The edge-annotation firewall now refuses user labels in the lowering's
reserved _:fluree_ann_ prefix, which would merge with the lowering's
anonymous annotation nodes.

Keywords on node objects no longer leak into the data as predicates named
after the keyword:

- @reverse (JSON-LD 1.1 section 4.8): each value is the subject of a
  statement pointing at the node, written in the node's scope. The
  expander used to write a context term defined with @reverse as a
  forward property, inverting the statement; it now expands into the
  node's @reverse map, as the keyword does.
- @included (section 4.7): the included nodes are written in the node's
  scope with no linking statement.
- @nest (section 4.6): the expander merges a nested value's properties
  and types into the enclosing node, recursively; a nested value cannot
  carry @id or @graph.
- @index carries no statement and is dropped.
- Any other key of JSON-LD keyword form (@ then letters, e.g. @language
  on a node) is refused. Keys that merely start with @ (@odata.etag) are
  ordinary property names, as before.

Bulk import reads @reverse and @included the same way (they were
dropped). The edge-annotation lowering treats @included nodes as nodes
and refuses an annotation inside @reverse or @nest, which it would have
lowered against the wrong edge.

…itter

The edge-annotation lowering computed "which graph is this edge in" on
its own, and disagreed with the parser: it ignored the update's graph key
(A1: the annotation was refused as a GraphMismatch), the ["graph", g, ...]
item (A2) and the array selector (A3), writing the bundle to the default
graph without an anchor while the edge was in g, and never lowered
annotations inside named-graph content.

- The walkers read @graph with the shared classifier and is_graph_key
  (aliases included; the root document's bare `graph` routing key is not a
  selector), recognize ["graph", g, ...] items in update clauses, and
  descend into named-graph content with the graph's @id as the scope.
  Siblings are placed with the edge's scope as their graph selector, which
  the parser resolves exactly as it resolved the edge's. attach_siblings
  reads the document shape: a top-level named graph is re-wrapped, not
  appended into its content.
- GraphScope::emit is the one template-level writer of f:reifiesGraph: a
  reifier's f:reifiesSubject emitted in a named scope brings
  (reifier, f:reifiesGraph, scope graph) with it, for assertions and
  retractions alike. The walkers' stamps and graph insert's post-hoc
  anchor loop are deleted.
- With #1997, an update's `graph` key that names the ledger's own address
  writes the default graph: staging moves the templates of that template
  default there. An annotated edge under it now moves with its bundle,
  and staging drops the bundle's anchor, which named the address: a
  default-graph bundle has none, so the annotation is found with its edge
  in the default graph.
- A fail-closed cross-check: after an annotated document parses, every
  reifier bundle must reify an edge asserted in the bundle's own graph.
  It runs once any template names a graph (a document entirely in the
  default graph has no scoping to disagree about) and allocates nothing
  per template, which keeps the annotation parse bench within noise.

A node-level "@graph" selector in a where node-map now scopes that
node's patterns (and those of nodes nested in it) to the named graph,
exactly as ["graph", <name>, {...}] does, so the same key means the same
scope in where, delete and insert. It used to be parsed as a predicate
named @graph: a query matched nothing, and an update's WHERE matched
nothing, so the update committed zero flakes and its target survived.

The name follows the existing where-clause GRAPH rule (an alias or the
graph's IRI as written); a context alias of @graph works the same way,
and a bare `graph` key stays an ordinary property in a pattern. A node
with @graph content (a JSON-LD named graph) is refused in a where.

The bulk-import JSON-LD adapter skipped every @-key but @type, so a
node's graph selector was dropped (its statements folded into the
default graph) and a JSON-LD named graph's content never reached the
sink. The GraphSink contract calls that folding data loss. The adapter
now refuses a node-level @graph (selector or content) with a message
pointing at `fluree insert` or a TriG / N-Quads import. Writing graph
scopes from bulk JSON-LD (ImportSink quads) is left for a follow-up; a
top-level envelope is unwrapped by expansion and imports as before.

The config reader took the first binding of a setting-group pointer, so
a config with two f:shaclDefaults values (a re-inserted config) could
read either group, and a group whose fields were written outside the
config graph (the #1979 shape) read as a present-but-empty group.

- A group that sets nothing in the config graph reads as absent. That is
  observably the same as before for every group; it makes the reader
  deterministic and keeps "empty group" from diverging from "no group".
- Several values of one pointer: empty groups are skipped and the rest
  ordered by decoded IRI, the rule several f:LedgerConfig subjects
  already follow. A rate-limited warning names the pointer.
- config_resolver::diagnose reports degenerate config state: several
  f:LedgerConfig subjects, ambiguous group pointers, empty groups and
  the graphs their fields were stranded in, and shapes that no config
  enables ("shapes present; SHACL enforcement not configured").
- Ledger info carries them as `configDiagnostics` (omitted when there
  are none), and `fluree info` prints them.

The SHACL enforcement tests relied on shapes alone enabling validation (the
shapes-exist heuristic), which the next commit removes: shapes will be
enforced only where the ledger config sets f:shaclEnabled true. Each test
that exercises enforcement now writes that config with its shapes.

- shacl_tests.rs: every ledger is created by create_shacl_ledger, which
  commits the enabling config after creation.
- tests/support: shacl_enabled_config_node() (a context-free config node
  for a test's @graph) and enable_shacl().
- it_branch_shacl, it_config_graph (shacl_config_disables_validation,
  shacl_turtle_insert_rejected_when_violating), it_optimistic_rebase,
  it_graphql_mutations and the server's graphql_http_integration write the
  config beside their shapes.

No behavior change: every migrated test passes with the heuristic present,
and (checked with the heuristic removed) passes on the config alone.

Fixes the other half of #1979: a ledger with shapes and no config enabling
SHACL enforced them anyway (the shapes-exist heuristic), while any config
switched that off unless it also set f:shaclEnabled true. SHACL is now
enforced exactly where the effective config (ledger-wide merged with the
graph's override) sets f:shaclEnabled true, as override-control.md and
setting-groups.md already document. Breaking for ledgers that relied on
shapes alone: they stop enforcing until SHACL is enabled in config (ledger
info reports "shapes present; SHACL enforcement not configured").

- apply_shacl_policy_to_staged_view: the config-driven per-graph map is the
  only source of participating graphs. When no graph participates it
  returns before compiling shapes. Every lane shares it: JSON-LD and SPARQL
  transactions, Turtle insert, branch merge/rebase/revert, push.
- validate_view_with_shacl takes the per-graph map as required, so "no map
  means validate every graph in Reject" cannot be expressed.
- Inline request shapes (opts.shapes) are a request-time setting: they
  validate every user graph the transaction writes, in the requested mode,
  in a pass of their own compiled from the request's bundle alone, so they
  never switch the ledger's stored shapes on. Each graph's effective SHACL
  override control gates them (not f:shaclEnabled); where it refuses them
  (f:OverrideNone, or f:IdentityRestricted without a matching verified
  identity) the transaction fails with RequestOverrideRefused (400) rather
  than committing unchecked data. The stored-shape compile cache no longer
  goes unused when a request carries inline shapes.
- Inline request shapes are not supported in a policy-scoped request: one
  with a policy context that restricts anything or with policy inputs on
  the HTTP request, or on a ledger whose config sets policy defaults
  (ledger-wide or for any graph) other than an unrestricted
  f:defaultAllow true. Such a transaction fails with "Unsupported feature:
  inline request shapes are not supported in a policy-scoped request"
  (400). Support for inline shapes in policy-scoped requests is a
  follow-up.
- CLI and GraphQL texts that described shapes as activating validation are
  corrected.

Tests: the heuristic test becomes shacl_shapes_without_config_do_not_enforce
(the #1979 control; config_write_json_ld_nested_groups_land_in_config is its
enabled twin), and the heuristic's warn-refusal test is removed. New: the
explicit-only matrix over SPARQL-written configs, the Turtle, merge and push
lanes without config, and the inline-shapes rows (shaclEnabled false,
OverrideNone with nothing committed, IdentityRestricted, per-graph refusal,
warn mode, stored shapes untouched, and the policy-scoped refusals, embedded
and over HTTP).

A data ledger whose config names a cross-ledger shapes source, with
f:shaclEnabled false, refused every write once the model ledger went away,
including the config write that would fix it: the transaction path resolved
the shapes wire, the model ledger and the cross-ledger schema before it
looked at whether SHACL was enabled. A local f:shapesSource naming a missing
graph, and uniqueness with a cross-ledger constraints source, bricked config
repairs the same way. Uniqueness also read a config it failed to load as "no
config", so a read error admitted the write unchecked.

- apply_shacl_policy_to_staged_view owns resolution: it computes which
  written graphs participate (stored shapes where config enables SHACL,
  inline shapes where override control permits them) and returns before
  resolving any shapes source, schema source or model ledger when none
  does. Callers pass the per-transaction ResolveCtx instead of pre-resolved
  wires; the pre-resolution in the JSON-LD/SPARQL, Turtle insert and branch
  operation paths is gone. Push has no resolver and keeps skipping
  cross-ledger re-validation. A stored graph's participation is decided per
  written graph, so a graph the transaction does not write never triggers
  resolution.
- The system graphs (#config, #txn-meta) never participate in SHACL or
  uniqueness, so a transaction that writes only config resolves no shapes,
  schema or constraints source and is never refused because one is
  unavailable. Data writes where enforcement is on still fail closed, with
  the resolver's error naming the model ledger.
- Config is read once per transaction, after staging, and shared by SHACL
  and uniqueness; a read error now fails the transaction on every lane
  (uniqueness included), and a transaction that writes only system graphs
  reads none.
- build_transact_policy_context resolves a cross-ledger schema source only
  when it builds a policy context, so a write without policy does not depend
  on that model ledger either. Policy sources are unchanged and still fail
  every write closed, config writes included: policy decides who may write
  the config.
- The Turtle insert path now reads the cross-ledger schema source for SHACL
  targeting, as the other lanes do.

Tests: the dropped-model brick with SHACL off, the fail-closed pair with a
JSON-LD and a SPARQL config repair, a cross-ledger schema source with SHACL
off, the local unknown-shapes-graph analog, the uniqueness analog, the
policy counter-test, and an injected config read failure that refuses a
uniqueness-governed write.

Ledger configuration is read only from the ledger's own config graph, from
one f:LedgerConfig subject, taking one value of each single-valued setting.
Writes that break this committed and then quietly did something else: a
setting group whose fields landed in another graph read as empty (#1979),
a config typed in another graph was never read, and of two values for one
setting the reader picked one. The guard refuses each before commit, as a
Parse error (HTTP 400) whose message says how to write it:

- a config edge (f:*Defaults, f:graphOverrides, f:overrideControl, the
  source and reference edges) written into the config graph whose target
  node gets f: fields in another graph in the same transaction;
- rdf:type f:LedgerConfig / f:GraphConfig written outside the ledger's own
  config graph;
- a single-valued config predicate that would hold more than one value
  after the transaction (pre-transaction values, less those retracted, plus
  those asserted), or a second f:LedgerConfig subject. Writing the same
  value again is not refused.

The guard reads only the staged flakes and the pre-transaction config graph,
never a shapes, schema, constraints or policy artifact, so a config repair is
judged by it alone. One pass over the staged flakes establishes that a plain
data transaction writes nothing config-shaped, so it costs no more than the
reasoning-mode check it absorbs. It runs where transactions are authored:
JSON-LD and SPARQL transactions and, newly, Turtle insert. Commit replay and
bulk import skip it.

The test seeding two f:LedgerConfig subjects now writes them unchecked, as
history written before the guard would reach a ledger.

- reference/compatibility.md: behavior changes for this release. SHACL is
  enforced only where the ledger config enables it (breaking), inline
  request shapes follow override control and are not supported in
  policy-scoped requests yet, config writes are checked and config-only
  writes are never blocked by validation artifacts, and JSON-LD nested
  nodes follow their enclosing graph (named graph objects are stored);
  JSON-LD 1.1 support list updated (named graph objects, @reverse,
  @included, @nest; @index ignored; other @-keywords refused).
- ledger-config/writing-config.md: nested groups inherit the node's
  @graph; the "config" keyword, the named graph form and the update graph
  key; enabling SHACL on the existing config subject; what a config write
  is checked for; the repair recipe for configs split by #1979.
- setting-groups.md, guides/cookbook-shacl.md, cli/model.md,
  cli/graphql.md: shapes alone never enable SHACL; the explicit-only truth
  table; inline shapes under override control.
- transactions/insert.md and update-where-delete-insert.md: named graphs in
  JSON-LD, nested inheritance, "default" / "config", variable graphs,
  relative graph names refused.
- concepts/reasoning.md (config written to the config graph),
  indexing-and-search/fulltext.md (the HTTP recipe posts to /insert),
  reference/vocabulary.md (txn-meta query through from),
  concepts/datasets-and-named-graphs.md, cookbook-edge-annotations.md,
  cli/info.md (config diagnostics).

Tests run the documented enable recipes, the JSON-LD config forms, the
graph-key update and the fulltext verification query.

With no top-level @id, a one-element array [{"@id": X}] was an envelope
but the same value as a single object {"@id": X} was read as a graph
selector: the document became an anonymous node in a new graph X, and its
other keys (f:message and the like) were written there as data instead of
being transaction metadata. Solo's MCP stamp_provenance produces exactly
that shape when an agent upserts a context-free bare reference. Base
refused it ("Insert must contain at least one predicate or @type").

is_envelope_graph now reads a single node object at the top level the way
it reads the one-element array (below the top level both bare forms stay
selectors), which restores base's reading for doc_shape, the expander and
txn-meta alike. The annotation walker reads the document's own @graph
through the same predicate, so it cannot disagree with the parser about
the root.

Tests: doc_shape table rows; txn-meta keeps its siblings for both forms;
the stamp_provenance shape gives the same outcome in both forms for insert
and upsert and registers no graph named after the reference.

The node-level @graph sugar in `where` took the graph name as written
(an alias or a full IRI), while the same key in `insert`/`delete`
expands compact IRIs and resolves keywords. One document, one name, two
graphs: `{"where": {"@id": "ex:a", "@graph": "ex:g", …}, "delete": {"@id":
"ex:a", "@graph": "ex:g", …}}` matched nothing and deleted nothing.

- The resolution order (variable, fromNamed alias, keyword, expansion
  against the @context) is now one function, classify_written_graph_name
  in fluree-db-query, and both sides call it: the template resolver in
  the transact parser and the where sugar, which maps the result to a
  GRAPH name. An update's where knows its ledger and aliases, so
  `config` and `txn-meta` name this ledger's graphs there and aliases
  stay the name the dataset resolves; a query passes its fromNamed
  names so they stay aliases even under @base.
- `default` in a where matches the where's default graph. A where pattern
  cannot leave the graph an enclosing selector chose, so `default` inside
  one (node-level or ["graph", …]) is refused rather than silently kept in
  the outer graph.
- A nested node's own @graph in `where` now scopes that node's patterns,
  as a nested selector scopes a node in a template (it was read as a
  predicate named @graph).
- The ["graph", <name>, …] array form in `where` keeps taking its name as
  written; the docs say so.

Tests: the classifier's order; where-side resolution (compact names,
keywords, aliases, default, nested default refused) and the query alias
case; end to end, the where+delete update with "@graph": "ex:g" deletes
what the insert wrote, and `default` and `config` read their graphs.

The checks a staged write runs before it may commit lived in three
copies: stage_and_check (JSON-LD, SPARQL, TriG, upsert) ran the config
read, SHACL, uniqueness and the config guard; the plain Turtle insert lane
copied the config read, SHACL and the guard but not uniqueness, so a
duplicate a JSON-LD insert refuses committed there (its comment claimed
parity); and branch operations (merge, rebase, revert and their previews)
ran SHACL only.

check_staged_write is now the one tail: one pre-transaction config read
(enforcement_config), then SHACL, uniqueness and, for authoring lanes,
the staged-config guard. WriteChecks carries what a lane brings (the
request's SHACL inputs, inline unique properties, tracker, @context,
whether the guard runs); a branch operation brings nothing, and does not
run the guard here.

- The Turtle insert lane calls it, so it enforces uniqueness like the
  other lanes.
- Branch operations call it from validate_branch_op_view, so a merge,
  rebase or revert that would leave a duplicate unique value is refused
  like the transaction producing that state (behavior change: they
  enforced only SHACL). BranchOpValidation carries the rejection itself
  (a SHACL report or a uniqueness violation) and previews report either.
- enforcement_config decides "writes a user graph?" with an early-exit
  scan instead of collecting and sorting a graph id per staged flake, and
  written_user_graphs collects into a set.

Tests: a plain Turtle insert refuses the duplicate a JSON-LD insert
refuses; a general merge of a branch write that duplicates main's unique
value is refused, and its preview reports the violation.

A fast-forward adopts the source's commits as they are and skipped
validation on the premise that they "were validated when they were
authored". Nothing guarantees that commits authored on another branch
satisfy the target's configuration, and the general merge and rebase
paths validate the same change against the target, so a fast-forward
could bring in what they refuse. Uniqueness had the same gap.

A fast-forward into a target whose config enables SHACL or uniqueness
(ledger-wide or for any graph) now runs the checks a transaction writing
the adopted change would face: the source line's net change since the
target's head is staged on the target's pre-merge state and checked by
the shared tail (check_staged_write) under the target's pre-merge
config, before any commit is copied or the ref advanced. A merge whose
commits also change the target's config is judged by the config it
merges into, as a transaction's own config writes do not apply to it.
The apply's ref CAS expects the validated head, so a commit that lands
on the target in between fails the merge instead of slipping past.

A fast-forward into a target that enables neither is unchanged: no
validation, no staging. The only added work there is reading the
target's config, from the ledger cache when it holds the target at the
merge's head, else from a load of the target.

The merge preview reports validation for a fast-forward exactly when the
merge validates it; docs (branch CLI, endpoints, Rust API, server
integration, cookbooks) say so instead of "validated when authored".

Tests: a violating branch write fast-forwarded into a SHACL-enabled main
is refused (preview non-conforming, head unchanged) and the general merge
of it too; a conforming change previews validated and merges; an
ungoverned target fast-forwards unvalidated with no validation in the
preview; the pre-merge config decides both ways (SHACL switched off on
the branch is still refused, switched on is not validated); a uniqueness
twin. The pinned "fast-forward preview carries no validation" test is
replaced by the governed and ungoverned cases.

R1 refused a setting group split across graphs only within one
transaction, so the #1979 end state was still reachable in two accepted
writes: an edge into the config graph first and the group's fields later
in the default graph (a policy group's f:defaultAllow false lost, fail
open), or the fields first and the edge later (a SHACL group read as off).
Only ledger info's configDiagnostics reported it.

The guard now also refuses, in either order:
- f: fields a transaction writes in a user graph for a node the config
  graph's edges already point at (the config graph is read once);
- a config edge a transaction writes into the config graph to a node that
  already has f: fields in a user graph (that node's statements in the
  user graphs are read).
Fields the same transaction retracts do not count, so moving them into
the config graph together with the edge (the repair) is accepted. The
extra reads run only for a transaction that writes the config graph or
an f: field in a user graph; a plain data transaction still costs one
pass over its staged flakes.

Tests: both orders refused with the group, the edge, the fields and the
graph named; the edge plus the moved fields in one transaction commits
and enables SHACL.

A transaction body's `opts.shapes` and `opts.uniqueProperties` were read
only by the HTTP server's route. The embedded API and the CLI's local
mode parsed the same body and dropped them, committing a record the
caller had asked to be checked.

parse_rooted, which every surface's JSON transaction goes through, now
fills both from the body when the caller set neither programmatically
(the precedence validationMode already has): `shapes` must be a JSON-LD
object or an array of them, `uniqueProperties` an array of IRI strings,
and anything else is refused as a Parse error instead of being ignored.
Whether the constraints apply is still decided at staging: override
control and the policy-scope rule for inline shapes. A build without
SHACL support refuses a transaction carrying inline shapes rather than
committing it unchecked.

Tests: the parser reads both for an insert and an update, keeps a
caller's own options, and refuses malformed values; through the embedded
API a record breaking the body's shapes is refused (insert and update),
a conforming one commits, the body's shapes are refused in a
policy-scoped request, and the body's unique properties are enforced;
the CLI in local mode refuses and accepts the same way; without SHACL
support the inline shapes are refused.

- An edge annotation under a variable graph (["graph", "?g", …] or
  "@graph": "?g") is refused while parsing, with a message that says
  so. Flake generation used to fail on the reifier's f:reifiesGraph ?g
  anchor ("Raw IRI from graph source cannot be used as object").
- A graph insert or sync whose payload addresses another graph through a
  selector ("default" included) is refused as "must not address a graph
  other than the target"; it said "named graphs" even for the default.
- The shacl-not-configured diagnostic counts SHACL enabled for any graph
  (a graph override), not only the default graph's posture, so a config
  that enables SHACL for one graph is not reported as unconfigured.
- A new diagnostic, duplicate-graph-override: several f:GraphConfig
  overrides for one target graph, of which the reader uses one.

Tests: the variable-graph refusal for both spellings; the graph-insert
refusal for another named graph and for "default"; per-graph enablement
clears the diagnostic; two overrides for one graph are reported.

The behavior-change list in docs/reference/compatibility.md gains what
the review fixes changed: a fast-forward into a target whose config
enables SHACL or uniqueness is validated against that config as it was
before the merge; merge, rebase and revert enforce uniqueness, and so
does a plain Turtle insert; a transaction body's opts.shapes and
opts.uniqueProperties are read by the embedded API and the CLI's local
mode; a where node's @graph resolves its graph name as templates do.

The staged-config guard ran only where transactions are authored, and
branch operations stage commits nobody checked as a combination: a
merge can bring together a config edge written on one side and the
group's fields written outside the config graph on the other, each
accepted where it was made, and a revert can undo the repair of a split
group. The result is the #1979 state: a group that reads as empty.

Merges (fast-forwards included), rebases and reverts now run the guard
on what they stage, in a branch-operation scope. R2 is enforced when the
data is written; branch operations re-check the integrity of the
target's config groups (R1, within the change and across transactions,
and R3). A refusal is the same Parse error (HTTP 400) a transaction
gets; it names the target's config group and points at the repair
("Repairing a config split across graphs"), and previews report it.

- config_guard: GuardScope picks the checks (Authoring: all of them;
  BranchOperation: R1 and R3, with branch-operation messages), and a
  GuardError tells a refusal from a failure to read.
- check_staged_write returns StagedWriteError, Rejected (a SHACL or
  uniqueness violation, or a guard refusal) or Failed, so a branch
  operation reports a rejection without matching error variants
  (is_rejection is gone).
- A fast-forward into a target that governs no writes is checked too
  when the commits it adopts carry config settings (an f: predicate, or
  an f: type): fast_forward_base returns the target's state with whether
  it is governed, and validate_fast_forward stages the adopted change
  only when either holds. Every other fast-forward is unchanged.
- Docs: branch CLI, endpoints, server integration, Rust API, cookbook,
  writing-config (what a config write is checked for) and compatibility.

Tests: a merge refused for splitting a group the target linked after the
fork (the branch's field written through JSON-LD and through SPARQL);
a fast-forward refused for carrying a split group from before these
checks; a revert refused for undoing a repair; and, accepted with the
guard running, a merge while the target changes its config and a revert
of a config change. Previews report each refusal. A fast-forward into an
ungoverned target that carries no config settings is not validated.

R1's gate fired on any f: predicate written to a user graph and then
read the config graph: every edge-annotation write (its f:reifies*
bundle), every f:enforceUnique annotation and every policy document paid
a config-graph read for nothing.

R1 now counts only the predicates the config reader reads as a group's
fields: the group pointers and source edges, the single-valued settings,
and the multi-valued ones (f:policyClass, f:reasoningModes,
f:allowedIdentities). Other f: data in a user graph is data, and writing
it reads no config. The same set decides what counts as a stray field
within one transaction and across two.

Test: the config-field set is the reader's vocabulary; f:reifies*,
f:enforceUnique and f:allow are not fields.

A node-level "@graph": "default" meant the ledger's default graph in a
template and the WHERE's own default graph in a where. They differ when
the update's graph key (SPARQL WITH) or `from` gives the WHERE another
default graph, so the natural move from the default graph into g1,
{"graph": "ex:g1", "where": {…"@graph": "default"…}, "delete":
{…"@graph": "default"…}, "insert": {…}}, read g1 and moved nothing.

In an update's where, "default" now names the ledger's default graph, as
in the templates. When the WHERE reads another default graph, the where
reads the ledger's default graph by a name the update adds to its WHERE
dataset, only when the where uses it; GRAPH ?g never enumerates it.
Otherwise the patterns stay as they are.

The name contains a space, so no graph written under an IRI has it, and
an update refuses it where the update itself writes it: as a graph name
in the where (node-level or ["graph", …]), as a VALUES value, or as a
fromNamed alias. A graph registered under it anyway (the Turtle lexer
decodes an escaped space inside an IRI) makes an update that reads the
default graph by that name fail, rather than read that graph instead.

A where pattern still cannot leave an enclosing graph, so "default"
inside one is refused as before. In a query, "default" stays the query's
default graph.

Tests: the where-side resolution under another default graph, the
refusal inside an enclosing graph, the reserved name refused where an
update writes it, and the record that the where read by it; end to end,
the move under a graph key and under `from`, with its SPARQL spelling; a
graph named @default read by its name and listed by GRAPH ?g beside
such a where; the reserved name refused in each form; a graph registered
under the reserved name refused rather than read.