feat(graphql): GraphQL endpoint over a schema derived from the ledger - #1748

`docs/api/endpoints.md` pointed at `../design/cli-server-contract.md`, which
was never tracked in git — a planning-doc reference that shipped. The CLI
contract it wanted is `docs/cli/server-integration.md` ("Implementing Server
Support For Fluree CLI"), whose clone/pull section documents exactly the
remote-`t` preflight the note is about; repointed there.

Sweeping the rest of docs/ found the same class of problem elsewhere. All
verified against the actual target before repointing:

  memory/README.md, memory/concepts/recall-and-ranking.md
    ../docs/... resolved to docs/docs/ — dropped the extra segment
  cli/publish.md
    design/server-implementation.md never existed; server-integration.md is
    that guide
  cli/validate.md
    no cli/import.md; bulk import is documented under `create --from`
  api/headers.md
    no transactions/sparql.md; SPARQL UPDATE lives in query/sparql.md
  concepts/edge-annotations.md
    cypher.md moved under docs/query/
  contributing/tracing-guide.md
    dev-docs/ is not in this repo; bullet removed rather than left dangling

And eight dangling anchors, mostly headings that were renamed under links
that were not: rust-api "Bulk import (high throughput)", cypher "Names, and
opting into IRIs", policy-model "Combining algorithm", sharing-data's
numbered heading, and a `drop_ledger` link to a section this file never had
(now cli/drop.md).

`graph-sources/iceberg.md` had "Enabling local tables" as bold text with
three links already treating it as an anchor; promoted to a real heading so
they resolve.

Verified with a GitHub-compatible slug checker over all 280 files: zero
broken file links, zero broken anchors. Two subtleties that produced false
positives on the way, in case anyone rechecks: GitHub maps spaces to hyphens
1:1 rather than collapsing runs (so `--` anchors are legal), and it keeps
underscores in slugs.

`SystemTime::now()` panics on wasm32-unknown-unknown. It compiles there, so
nothing would have caught it until a browser build called `create_<T>`
without an explicit `id` — the one path that mints.

Uniqueness now comes from a process-lifetime counter, hashed under a
per-process random seed so minted IRIs do not read as a visible sequence.
Uniqueness is the property actually relied on: knowing another subject's IRI
grants nothing by itself, since reads are governed by policy. The previous
comment claimed unpredictability was a security boundary; it is not, and now
says so.

The rest of the crate is already clock- and filesystem-free. The workspace's
other `SystemTime` uses sit in file-storage code that is
`cfg(not(target_arch = "wasm32"))` gated, so they are safe by exclusion;
this one had no such gate.

Not reachable from the wasm32 CI gate, which checks fluree-db-api with
--no-default-features and so never compiles the graphql feature — the fix is
for anyone who does enable it on that target.

main's `autotests = false` landed after this branch forked, so the merge
silently stopped auto-discovering tests/graphql_http_integration.rs — the
crate's own harness_coverage guard is what caught it.

…nt limits

GraphQL was the one read surface with no ceiling. `LedgerExecutor::resolve` ran
`Fluree::query`, which is `query_with_options(.., default())` — no cancellation
handle, no timeout — and the route called `state.fluree.graphql` outside
`run_query_task`, so the handle the server installs for every other read could
not reach it. Fuel is no backstop either: the lowered query carries no
`opts.maxFuel`, so it runs untracked.

Thread `QueryExecutionOptions` through `LedgerExecutor` and wrap the route in
`run_query_task`, the same wiring `routes/query.rs` uses. One document's root
fields resolve concurrently, so they share a single handle: a timeout or a
client disconnect cancels the whole fan-out rather than whichever field checks
next. `graphql_with_options` / `graphql_transact_with_options` are the new entry
points; the existing pair delegates with defaults.

A timeout bounds how long one query runs, not how many a document launches, and
does nothing about recursion that happens before execution — so also add depth
and complexity limits. A derived schema is cyclic wherever one class references
another, so nesting depth is the caller's choice. Depth is checked twice:
`selection::walk` counts levels the way async-graphql's `DepthCalculate` does,
because `parse_query` and `selection::extract` run before `schema.execute()` and
a schema-level limit alone would let a deep document recurse through extraction
first. Complexity is left to the schema, where it bounds fields across every
alias and fragment.

Both are baked into the registered schema, which is cached per ledger version,
so they join `RegisteredKey` — otherwise the first request through would fix the
ceiling for every later one. Defaults are 15 and 1000, configurable as
`graphql_max_depth` / `graphql_max_complexity`, with 0 disabling either the way
`query_timeout_ms = 0` disables the timeout.

Also covers the policy boundary, which had no direct test: a denied class or
property is absent from the derived schema rather than present-and-empty, and a
policy view declines the schema cache key so one identity is never served
another's schema. Each new test was checked against a reverted fix.

`async_graphql_parser` counts recursion depth while *building the AST*
(`MAX_RECURSION_DEPTH = 64`), but pest has already descended the grammar
recursively with no limit of its own by the time that counter runs. A document
of a few hundred KB — `{ persons { persons { … } } }` nested ten thousand deep —
overflows the stack inside `parse_query` and aborts the process, which no caller
can catch. Measured: 1,000 levels is refused, 10,000 aborts.

The depth limit added alongside cannot cover this: it runs during
`selection::extract`, after the parse. So guard the raw document instead — an
O(n) scan bounding brace nesting, skipping strings and comments, at the same 64
the parser would itself have enforced. Both entry points check it, `is_mutation`
included: the route parses there first, so it would otherwise be the hole.

Also drop GRAPHQL.md. It was the working design record for this branch and the
design is settled; what outlives it — the gaps a user needs to know about —
moves into docs/query/graphql.md, which is where the two code comments that
referenced it now point.

Three review follow-ups, all cheaper to take before the feature lands than
after.

**Minted IRIs are 128 bits.** `new_id` hashed a process-lifetime counter under
one random seed and emitted 64 bits. Each writer in a clustered deployment seeds
independently, so uniqueness across the cluster was birthday-bound at ~2^32
mints, and the failure is silent: `create_<T>` lowers to an Insert, so a
collision merges the new subject's facts onto whatever already holds that IRI.
Two independent seeds put the bound at ~2^64, which is UUIDv4's. No clock and no
new dependency — `SystemTime::now()` panics on wasm32, which rules out a ULID or
UUIDv7, and the seeds come from the same `RandomState` the 64-bit form already
used. This is the one item here that is genuinely irreversible: a minted IRI is
permanent, so the width cannot be widened for ledgers already written.

**Each document is parsed once.** It was three times: once to decide whether the
operation writes, once to extract the selection tree, and once more inside
async-graphql. `PreparedRequest` does the parse, answers `writes()`, and carries
the document on to `selection::extract` and then to the executor through
`Request::set_parsed_query` — which `execute` uses as-is, with validation, the
depth and complexity limits included, still running on it. This also collapses
the stack guard to one site; it previously had to be repeated wherever a parse
happened, which is exactly the shape a future caller forgets. Replaces the
`is_mutation` free function.

**Nested `orderBy` compares integers exactly.** `compare_sort_values` went
through `as_f64`, which collapses `xsd:long` values past 2^53 onto one float, so
distinct values tied and a stable sort then ordered them by whatever the
hydration happened to produce. Compare as i64/u64 first. Pinned by unit tests on
the comparator rather than end to end: the arrival order masks the tie, and an
integration test that passes with the bug reverted is worse than none.