FC-878 No promise API for history-query - #4

… diagnostics, nits

Selected items from the additional review feedback. Each call
explained.

**#1 — Retry-fragility comment on `take(opts.shapes)`.** No retry
exists on the staging path today, but `take()` moves the inline
SHACL JSON off the txn, so a future retry would silently skip
inline-shapes validation on the second attempt. Hard invariant
comment added at the move site; if retry is ever added, defer
the take until after `stage_txn` returns successfully.

**#3 — `UnsupportedFeature` errors no longer carry an empty
`ledger_id`.** `resolve_graph_ref` rejected `f:atT` /
`f:trustPolicy` / `f:rollbackGuard` *before* verifying that the
ref was actually cross-ledger, so a misrouted same-ledger ref
hitting this path would have produced a confusing error with
`ledger_id: ""`. Reordered: the same-ledger-ref guard runs first,
binding `raw_ledger_ref` once; the unsupported-feature checks
now carry the real ledger id in every diagnostic.

**#4 — `f:atT` rejection breadth: audited, no gap.** All five
`f:GraphRef`-shaped predicates already reject `f:atT` at their
same-ledger entry points:
- `policy_builder::resolve_policy_source_g_ids`
- `tx::resolve_shapes_source_g_ids` (SHACL)
- `ontology_imports::resolve_schema_bundle`
- `tx::resolve_constraint_source_g_ids_for`
- `view::fluree_ext::resolve_local_rules_source_g_id`

Plus the cross-ledger `resolver` (now with non-empty ledger_id
per #3). Audit-only change; no code modification beyond the doc
note.

**#2 — Cross-ledger policy target IRI loss is now logged.**
`wire_to_restrictions` previously `filter_map`'d unresolvable
target IRIs and `for_classes` IRIs silently. A cross-ledger
policy could quietly narrow its scope on D if M referenced IRIs
D had never registered. Two `tracing::warn!` calls now surface
both cases with `restriction_id`, requested count, and resolved
count — operators can spot the silent narrowing in logs.

Kept the restriction even when targets become empty (rather than
dropping the whole restriction): same-ledger via
`load_policy_restriction` also produces empty target sets for
the same IRI-not-in-snapshot scenario, and dropping the
restriction would diverge cross-ledger from same-ledger
semantics. The warn log is the parity-preserving signal.
`fluree-db-policy` gains a `tracing` dependency for this.

**Nits taken:**
- `TAtUnavailable` doc-commented as Phase 3 reserved (unreachable
  today because `UnsupportedFeature { feature: "f:atT" }` fires
  first).
- Empty `uniqueProperties: []` over HTTP is now documented as an
  intentional "no inline constraints" treatment, not a silent
  bug.
- Cache read/write race in `resolver` documented as benign:
  losers materialize the same value structurally; single-flight
  is a future optimization, not a correctness need.
- `f:AccessPolicy` IRI promoted from local `const` /
  duplicated-literal to `fluree_vocab::policy_iris::ACCESS_POLICY`.
  Two call sites updated; nothing else used the local consts.

**Nits skipped per "don't make changes that don't seem needed":**
- HTTP-level negative test for malformed `opts.shapes` /
  `uniqueProperties` (#5) — unit-level coverage exists; HTTP
  harness setup cost not justified.
- Same-ledger `rules_source_g_id` end-to-end test (#6) — already
  covered by `it_rules_source::rules_source_in_named_graph_is_honored`,
  which runs an actual query against the named-graph rule.
- DynamoDB hard-drop failure handling (#7) — storage layer,
  unrelated to this PR.
- Duplicate pattern match in `shapes_materializer` —
  cosmetic.
- `snapshot.ledger_id` redundancy in inline-shapes / inline-
  ontology `txn_id` — cosmetic.
- `is_last_live_branch` WARN log — unrelated path.

An aggregate over a computed expression (e.g. `AVG(xsd:float(?n))`, `SUM(?n+1)`)
lowers its input to a synthetic `?__agg_expr_N` BIND, deduplicated by expression
via the `agg_expr_binds` cache. That cache was query-global, so two sibling
grouped sub-SELECTs sharing the same aggregate-input expression deduped to ONE
synthetic var — bound only inside the first sub-SELECT's WHERE. When the second
sub-SELECT (a separate execution scope) aggregated over that var, it was absent
from its schema, failing the join at plan time ("Projected variable not in child
schema" / "Aggregate input variable not found in schema").

Reset the cache at each subquery boundary (`lower_subselect` saves and restores
it), so every sub-SELECT emits its own input BIND while intra-scope CSE is kept.
A bare-variable aggregate or a single grouped sub-SELECT was unaffected — both
necessary ingredients (expression input + sub-SELECT child of a join) are now
covered.

Fixes benchmark-db bug #4 (BSBM BI query 5: per-side
`AVG(xsd:float(xsd:string(?price)))` over two joined grouped sub-SELECTs).
Pre-existing on main; surfaced by the BSBM BI harness. JSON-LD is unaffected
(its aggregate inputs are always explicit variables).

Addresses four review findings against the multi-query handler and
snapshot application.

Bearer ledger scope (High fluree#1):

The handler now walks the validated distinct_ledgers set after
validation and rejects with 404 (existence-leak avoidance) if any
ledger is outside the bearer's read scope. Matches the single-query
/query and /query/:ledger behavior exactly: an unsigned bearer that
can't read one of the envelope's ledgers gets the whole envelope
rejected, not partial results that would reveal whether the ledger
exists. Signed requests bypass this check, same as single-query.

Identity + default policy-class threading (High fluree#2):

The handler builds a MultiQueryIdentityContext containing the
effective bearer identity (signed DID wins over bearer identity) and
the server-configured default policy class, threaded through to the
dispatcher. The dispatcher applies it per JSON-LD sub-query via
apply_auth_identity_to_opts — the same code path the single-query
JSON-LD handler uses, including the root-identity impersonation
semantic. The impersonation check binds to each sub-query's primary
ledger (first entry of its from clause), conservative for multi-
ledger sub-queries.

Headers are now injected into envelope opts BEFORE validation runs,
so a client supplying max-fuel or maxConcurrency via fluree-* headers
hits the same envelope-level rejections the body opts get.

The fluree-* headers (policy-class, policy, policy-values, identity,
default-allow, max-fuel) ride on the envelope opts and merge into
every sub-query's opts as defaults via merged_opts — sub-query opts
still win on key conflict, matching single-query behavior.

SPARQL identity threading is explicitly deferred: the existing
connection-scoped SPARQL path (/query with SPARQL FROM clauses) also
doesn't currently thread identity. v1 multi-query matches that for
parity; the docs flag this as a v1 limitation so the two paths can
land identity threading together.

SPARQL fragment-aware snapshot pinning (Medium fluree#1):

apply_snapshot_to_sparql previously skipped any IRI whose value
differed from its bare-ledger form via the value_str != bare check,
which fired on both real temporal pins AND on named-graph fragments
(ledger#txn-meta). So an envelope-pinned SPARQL like
FROM <mq:frag#txn-meta> would run against current head instead of
the envelope's t. Fixed by gating the skip on actual temporal-marker
presence (has_temporal_marker checks for @t: / @iso: / @commit:),
and splicing @t:N BEFORE any fragment when rewriting:
<ledger#txn-meta> -> <ledger@t:42#txn-meta>. The dataset parser
separates fragment from temporal suffix and reattaches the fragment
after time-spec resolution, so the spliced form is what it expects.

Per-sub-query response size cap (Medium fluree#4):

DispatchConfig now carries max_subquery_response_bytes. Each
sub-query's serialized result is sized once after dispatch returns;
if a single alias's result exceeds the cap it's downgraded to an
error outcome (code: "response_too_large") and the data dropped
before assembly. This catches a single runaway query before it adds
to envelope-wide memory pressure. The envelope-level cap in
assemble_response is still the strict guarantee; the per-sub-query
cap is the early-exit. The doc now spells out honestly that this is
best-effort, not an OOM guard — peak memory is bounded by
max_concurrency * max_subquery_response_bytes, not the envelope cap
alone — and per-sub-query streaming serialization is queued for v1.1.

Tests:

- 4 new auth integration tests (multi_query_auth_integration.rs):
  unauthenticated request when data auth required returns 401,
  in-scope bearer succeeds, out-of-scope JSON-LD returns 404,
  out-of-scope SPARQL returns 404.
- 1 new fragment-ledger SPARQL integration test confirms a
  SPARQL FROM <ledger#txn-meta> envelope alias runs successfully
  (regression against the unpinned-fragment bug).
- 2 new unit tests cover the SPARQL fragment splicing
  (apply_snapshot_to_sparql) for both FROM and FROM NAMED clauses.

47 server integration + 21 policy + 4 multi-query auth + 16 multi-query
core + 73 envelope/snapshot/dispatcher unit tests all green.

Adversarial review follow-ups on the subject-key heuristic:

- (#4 parity) The identifier_field_ids branch now emits SubjectKeyUnverified for
  each key column - uniqueness is unverifiable metadata-only (NDV deferred) even
  for a declared identifier, matching the override and <STEM>_KEY/_ID branches.
  The non-null gate already handles composite keys (rejects if ANY member is
  nullable). Existing tests that asserted no diagnostic for a clean identifier
  hint are updated.

- (#5 emitter fixture) Adds an emit-level test that a partially-covered stat
  (null_fraction == None, unknown) on a non-`required` identifier is NOT treated
  as a safe subject key (is_non_null is false), while full coverage proving
  null_fraction == 0 makes the same column safe - composing the partial-coverage
  fix with the non-null gate. The shared fixtures only set null_fraction from
  `required`, so this builds the column explicitly.

Refs fluree/solo#724

Address the review's findings — all verified real; all make the harness's
green trustworthy rather than changing what it covers:

- (review #1) the 'no unexpected named graph' guard was dead code: the
  engine binds GRAPH ?g as a plain literal, so the Iri-only filter in
  list_named_graphs always produced []. Accept literal and IRI bindings
  (excluding the alias-named default graph) so the guard survives the
  eventual engine fix. Verified live: an update leaving a stray graph with
  no expected graphs now fails with 'Unexpected non-empty named graph'.
- (review #2) bail when a manifest yields zero tests — a submodule
  restructure or manifest-parser regression must not report green.
- (review #3) a registered test that dies by timeout/subprocess crash now
  hard-fails: the register excuses a known wrong answer, not an infra
  death masking a new hang or panic.
- (review #4) UpdateEvaluationTest now rejects an mf:result blank node
  exposing none of ut:data/ut:graphData/ut:result, instead of degrading to
  a trivially satisfiable 'expected empty store'.
- (review #5) register entries matching no discovered test now fail the
  suite, so dead entries (typos, upstream renames) cannot accumulate.
- notes: tightened the TSV bare-integer heuristic to a single optional
  leading sign; documented the line-based directive-hoisting assumption;
  fixed the stale 'CI runs make ci' Makefile comment.

Full suite remains green: 36 suites, ~1420 tests, 0 failed, 0 ignored.

Four additions, one per open review item:

- Multi-op atomicity on mid-request failure (review blocking #4): op 1
  INSERT DATA stages cleanly, op 2 fails at staging while evaluating
  over op 1's data (BIND(STRDT(?m, <bad:datatype>)) — proving op 2 ran
  against the sequential state); the request errors as a unit, 't' is
  unchanged, and op 1 leaves no trace.
- UPDATE BASE resolution at the seam (review blocking #2): the same
  BASE-carrying document stores and finds identical absolute IRIs on
  the update and query surfaces, GRAPH names included.
- DELETE WHERE label independence at the seam (review blocking #5):
  label reuse across DELETE WHERE ops executes, each op deleting its
  own matches.
- Indexed EXISTS-with-GRAPH-?g (review blocking #3): the
  GraphVarCorrelated strategy driven end-to-end on a binary-indexed
  ledger — including the string-literal back-compat — which no
  memory-backed suite (W3C harness included) ever exercised.

On the #1443 EncodedSid/EncodedLit extraction arms specifically, the
audit went one step past the review's finding: no current plan shape
delivers a still-encoded binding to either extraction site (probed:
plain join, OPTIONAL, FILTER EXISTS, UNION, string variant — upstream
operators materialize batches first). The arms stay as defense-in-depth
with their comment rewritten to say exactly that (this also retires the
stale 'never on a scan hot path' wording the review flagged).