@fuzdev/fuz_app 0.147.0 → 0.148.0

package/dist/testing/CLAUDE.md

@@ -79,6 +79,15 @@ across the auth test suite. Use for query-level tests needing real DB rows
 but not a full session/token bundle. For tests also needing an API token +
 session cookie + role_grants, use `bootstrap_test_keeper` from `app_server.ts`.
 
+`create_test_extra_actor(db, account_id, name)` adds an actor to an
+account — the multi-actor edge — with `created_at` read from the wall clock
+(`clock_timestamp()`), not the transaction-fixed `NOW()` default. Actor lists
+sort `created_at, id`, so a shared `created_at` would order them by random id;
+seeded through it, the account's first actor sorts first and the extras in
+insert order. `_testing_reset` and the in-process setup seed `extra_actors`
+with it, as the Rust reset does with `query_create_actor_with_clock_timestamp`,
+so both spines list a multi-actor keeper's actors in one order.
+
 `create_test_role_grant_direct(db, input)` wraps `query_create_role_grant`
 for tests needing an active role_grant seeded directly, bypassing the
 production offer/accept consent flow. Use only when the test focuses on
@@ -103,6 +112,7 @@ mismatch.
 ### `audit_drift_guard.ts` — audit-emission validation
 
 - `install_audit_drift_guard()` — `beforeEach` resets + `afterEach` zero-checks the `audit_metadata_validation_failures` + `audit_unknown_event_type_failures` counters from `auth/audit_log_queries.ts` and the emitter's write-failure counter (`get_audit_write_failures` in `auth/audit_emitter.ts`). Call once at the top of any `describe_db` block firing audit emits — production validation and the emitter's write are fail-open, so without this any regression shipping a typo'd `event_type` or undeclared metadata field, or losing a row the database refused, is silent. A test that fails a write on purpose resets the counter (`reset_audit_write_failures`) once it has asserted it.
+- `assert_audit_event_metadata(event, {reject_unknown_keys?})` — the wire-side twin: parses a read audit row's `metadata` against its builtin event type's `audit_metadata_schemas` entry as declared, so a mistyped, `null`, or missing field fails while a consumer-added key passes (the schemas are `z.looseObject`, and a builtin's schema can't be overridden, so added keys are a consumer's only extension path). `reject_unknown_keys` closes the world: an undeclared key fails too, for a suite whose backend adds none. The wire schema leaves `metadata` a loose record and only the TS spine validates it, at insert and fail-open, so this is what holds every spine's rows to their event's contract. A consumer-registered event type passes unexamined. `list_audit_events` and the admin suite run it on every row they read, with `reject_unknown_keys` from the fixture's `reject_unknown_audit_metadata_keys` (a setup option on `default_cross_process_setup`, `default_in_process_setup` and `default_in_process_suite_options`); fuz_app's own spine wiring turns it on.
 - `assert_no_audit_drift()` — the zero-check itself, for a test that manages the counters. Pair with `await_pending_effects: true` (the `create_test_app` default) so fire-and-forget audit writes complete by response time.
 - `create_recording_audit_emitter(calls_ref?)` — no-op `AuditEmitter` pushing every `emit` and `emit_pool` call into `calls`. Pass `calls_ref` to write into a caller-owned array; omit to let the helper allocate. Returns `{emitter, calls}` — destructure `emitter` as the `audit` dep and read `calls` to assert. `add_listener` records (never fires) and returns a remover with the production semantics, so `listener_count` tracks what a server registered and released. Replaces per-file capturing emitters previously duplicated across `password_change.test.ts`, `audit_log.test.ts`, etc.
 - `RecordingAuditEmitter` — `{emitter: AuditEmitter; calls: Array<AuditLogInput>}`.
@@ -295,6 +305,87 @@ assert_schema_snapshots_equal(snapshot_deno, snapshot_rust, { a: 'deno', b: 'rus
 Each impl's _own_ tests still gate its DDL correctness independently — this
 pair is purely the cross-impl drift check.
 
+## Cross-impl differential
+
+The behavioral twin of the two parity gates above: where they compare
+declarations (DDL, the method set), this compares answers. Each impl is the
+oracle for the other — a case the table pins by status alone, or an extra
+field a loose output schema passes on one spine, shows up as a difference.
+
+- `cross_backend/differential_normalize.ts` — `normalize_differential_response({status, headers, body})`
+  → `DifferentialResponse` `{status, body, header_names}`. Volatile values
+  become positional placeholders per kind (`VOLATILE_VALUE_PATTERNS`: API
+  tokens, `tok_` token ids, lowercase UUIDs, `ISO8601_SECONDS` timestamps,
+  bare 64-hex digests — matched inside any string, object keys included): the
+  first UUID is `<uuid:1>`, a repeat of it `<uuid:1>` again, so identity
+  relations within one response survive while the values differ across
+  backends. Placeholders are positional, not tied to fixture identity, so two
+  ids that appear once each and trade places normalize equal. Only the
+  canonical spelling is placeholdered — an uppercase UUID or a millisecond
+  timestamp stays raw and differs — and a `blake3:` content address is
+  compared verbatim (equal bytes hash equal on both spines). Keys are sorted (and visited
+  in that order when numbering); array order is kept. `header_names` is the
+  sorted name set minus `VOLATILE_HEADER_NAMES` (framing and per-request
+  headers each server sets its own way); values are never compared —
+  `set-cookie` carries a fresh credential, and the contract header values are
+  the conformance table's `expect.headers` + no-fingerprint floor.
+  `diff_differential_responses(a, b)` → `DifferentialDiff[]`, one per leaf
+  path (`status`, `headers.<name>`, `body.error.data.reason`; an object one
+  side lacks diffs key by key, and an empty one against a missing one at its
+  own path), `differential_path_covers(covered, path)`,
+  `format_differential_diffs(diffs, labels)`.
+- `cross_backend/differential.ts` —
+  `describe_differential_conformance_tests({cases, backends: [a, b],
+  surface_source, rpc_endpoints, live_rpc_endpoints?, session_options,
+  principals?, known_divergences?, suite_name?})`, each backend `{name,
+  setup_test, ws?}`; methods resolve as the table resolves them
+  (`resolve_conformance_rpc_endpoints`).
+  `ws` on both runs the cases over their WebSocket endpoints, filtered by
+  `is_ws_conformance_case`, with the ledger checked against what is left; on
+  one alone, registration throws. Per case, each backend's own `setup_test`
+  (separate databases and keepers), the principal resolved and the request
+  sent through `send_conformance_case` (`conformance_table.ts`), both answers
+  normalized and diffed. The per-case `expect` is not asserted —
+  each backend's conformance leg holds it. `KnownDivergence` is the ledger
+  row: `{case_name | method, tracking_id, reason, what_differs}`, the names a
+  string or a list, `what_differs` the diff paths covered (a path covers
+  everything under it), each a string or a `KnownDivergencePath`
+  `{path, a?, b?}` pinning the value a side shows there (`undefined` for
+  nothing). A pin is compared with the normalized leaf value at the differing
+  path, so a placeholdered value never matches the raw one, an object pin
+  must list its keys sorted, and a parent-path pin never matches. A case may
+  differ at the paths of the entries it matches, with their values, and
+  nowhere else. `xfail_until`'s turns-red semantics clean
+  the ledger: a case a `case_name` entry names must still show it (checked in
+  that case's test), a `method` entry must still show on one of its cases
+  (checked by a closing test once they all ran — a filtered or failed run
+  leaves it unjudged, and the test skips when nothing was judged), and an
+  entry matching no case, or listing a case name that doesn't exist or a
+  method no case sends, fails —
+  the static half is `check_known_divergence_ledger(cases, ledger)`, exported
+  for checking a ledger without a backend. No other ignore path exists.
+
+fuz_app runs it under the `cross_backend_parity` project
+(`differential.cross.test.ts`, its ledger `differential_known_divergences.ts`
+in `src/test/cross_backend/`): every `conformance_*_cases.ts` array plus the
+generated auth rows (over the live mount too, so the cell verbs, the actor
+resolvers and the `_testing_*` backdoors are compared), TS spine vs
+`testing_spine_stub`, both on Postgres so no engine difference reads as a body
+difference. The same cases run again over
+WS, against `differential_ws_known_divergences` (the HTTP ledger without its
+header row). The multi-actor `conformance_acting_cases.ts` rows run with the
+generated rows on a keeper seeded with `extra_actors`, over both transports.
+The TS spine runs under `DEV` there, so its DEV-only diagnostics (Zod
+`issues` on `invalid_params`, the `X-Fuz-Auth-Debug` header) are ledger rows.
+The suite composition is `describe_spine_differential_suites`
+(`src/test/cross_backend/spine_differential.ts`), which takes the two
+backends and their ledgers. fuz_app also holds two TS runtimes to each other
+with it: the `cross_backend_ts_differential` project
+(`differential_ts.cross.test.ts`) dual-spawns the TS spine binary on Node and
+on Bun, both on `memory://`, against an empty ledger — both run under `DEV`,
+so the DEV-only rows show on both sides and differ nowhere. It needs no Rust
+or Postgres and runs in the `cross-ts` CI job.
+
 ## Assertions, coverage, helpers
 
 ### `assertions.ts` — surface + error-schema assertions
@@ -432,7 +523,7 @@ Also exported: `describe_adversarial_auth(options)` (group 3 on its own) and
 `build_error_schema_lookup(specs, middleware_specs?)` (pre-built
 `Map<string, RouteErrorSchemas>` for per-response validation).
 
-### `adversarial_input.ts` — schema-walk payload generation
+### `adversarial_input.ts` + `adversarial_input_cases.ts` — schema-walk payload generation
 
 `describe_adversarial_input({build, roles})` — fires input body / params /
 query validation failures at every route with correct-auth credentials so
@@ -440,11 +531,12 @@ validation middleware is actually exercised (not short-circuited by 401).
 All cases expect 400 with one of `ERROR_INVALID_REQUEST_BODY` /
 `_INVALID_JSON_BODY` / `_INVALID_ROUTE_PARAMS` / `_INVALID_QUERY_PARAMS`.
 
-Exported generators:
+The generators live in the hono-free `adversarial_input_cases.ts`, so the
+cross-process suites reuse them:
 
-- `generate_input_test_cases(input_schema)` — whole-body structural (non-object, extra key when `strictObject`), missing required fields, one wrong-type per field, null for required non-nullable, one format violation per constrained field, numeric/array/string boundary cases via JSON Schema introspection.
-- `generate_params_test_cases(params_schema)` — format violations only (unconstrained string params accept anything).
-- `generate_query_test_cases(query_schema)` — missing required + format violations.
+- `generate_input_test_cases(input_schema)` → `InputTestCase[]` — whole-body structural (non-object, extra key when `strictObject`), missing required fields, one wrong-type per field, null for required non-nullable, one format violation per constrained field, numeric/array/string boundary cases via JSON Schema introspection.
+- `generate_params_test_cases(params_schema)` → `ParamsTestCase[]` — format violations only (unconstrained string params accept anything).
+- `generate_query_test_cases(query_schema)` → `QueryTestCase[]` — missing required + format violations.
 
 GET-with-input routes hit the RPC `?params=` query convention; invalid-JSON
 arrays there collapse to `ERROR_INVALID_REQUEST_BODY` (schema failure)
@@ -509,9 +601,15 @@ the response against declared schemas. DB-backed via `create_test_app`.
 Per-route test (`test.each`) — one line per route in the vitest output.
 
 Options: `{setup_test, surface_source, skip_routes?, input_overrides?, success_fixtures?}`.
-`input_overrides` is a `Map<"METHOD /path", body>` — override generated
-bodies for routes whose input schema can't round-trip cleanly (e.g. fields
-that must reference DB state).
+Principals and the 401 check are the RPC round-trip's (`pick_auth_principal`;
+`assert_route_authenticated` over `is_unauthenticated_refusal`, reading the
+flat `error`), and a non-`GET` route called as the authed
+account runs on a fresh account — a generated logout would otherwise end the
+shared session, leaving `/password` and every later authed route a vacuous
+401. `src/test/testing/round_trip.test.ts` pins both, the RPC test's twin.
+`input_overrides` is a `Map<"METHOD /path", body>` — override generated bodies
+for routes whose input schema can't round-trip cleanly (e.g. fields that must
+reference DB state).
 
 SSE routes are skipped by Content-Type sniff; `describe_sse_route_tests`
 picks them up separately.
@@ -521,9 +619,62 @@ picks them up separately.
 DB-backed round-trip for RPC: one POST test for all methods, one GET test
 for `side_effects: false` methods. Successful responses validate against
 `action.spec.output`; error responses validate as well-formed JSON-RPC error
-envelopes. Options: `{setup_test, surface_source, session_options, rpc_endpoints, skip_methods?, input_overrides?, success_fixtures?}`.
-The admin RPC auth test picks a session-based identity (`authed` / `admin` /
-bootstrapped keeper) based on `method.auth`; keeper uses the daemon token.
+envelopes. Three refusals fail instead of passing as an envelope: `method not
+found` (the backend lacks a method the surface declares), a crash — HTTP
+500, the `internal_error` code (-32603), or a ≥500 whose body is no JSON-RPC
+envelope — and a 401 to a non-public call (`assert_rpc_authenticated`): the
+call carried a credential its auth admits, so a 401 means it stopped working.
+A public method may still answer 401 (a wrong-password login), and so may a
+handler naming its own reason (below). A ≥500 carrying a declared code
+(`service_unavailable` 503, `timeout` 504, a consumer code mapped in
+`JSONRPC_ERROR_CODE_TO_HTTP_STATUS`) is a server condition and passes like a
+4xx. The failure names the method, status, code and message; a non-JSON body
+is reported as text. Options: `{setup_test, surface_source, session_options,
+rpc_endpoints, skip_methods?, input_overrides?, success_fixtures?}`.
+`pick_rpc_auth` picks the principal from `method.auth` through
+`pick_auth_principal` (`integration_helpers.ts`, shared with the REST
+round-trip; `AuthPrincipal`): none for a public method, the keeper's daemon
+token when `credential_types` names it, the admin account's session for an
+admin-gated method, the keeper's session for another role, else the authed
+account's session. The 401 check is `is_unauthenticated_refusal`: a 401
+reading `authentication_required` or naming no reason fails; a handler's own
+401 reason on an authenticated call (`invalid_credentials` for a wrong current
+password) passes. So a handler that answers 401 to a valid credential must name
+its reason — `data.reason` over RPC, the flat `error` over REST: a reason-less
+401 reads as unauthenticated and fails the round-trip. TS's
+`jsonrpc_errors.unauthenticated(message)` sends no `data` unless given one, so
+pass `{reason}` as its second argument.
+
+A side-effecting method picked for the authed account runs on a fresh account
+of its own (`round_trip_uses_fresh_account`, keyed on the spec's
+`side_effects`): generated params omit optional fields, and an omitted target
+on a self-service method is the caller — `account_delete` with no
+`account_id` deletes it, `account_session_revoke_all` ends its session — which
+on the shared account would turn every later account method into a 401. Keyed
+on `side_effects` rather than a list of known destroyers, so a consumer's
+self-targeting method is covered without registering it. The keeper, its
+daemon token and the admin account stay shared (one keeper per fixture, and
+admin methods with generated nil ids target no existing account); a
+credential they lose still fails on the 401 check.
+`src/test/testing/rpc_round_trip.test.ts` pins both against a fake backend
+whose side-effecting method ends the caller's session.
+
+`success_fixtures` (`RpcSuccessFixtures`, method → `(fixture) =>
+Promise<RpcSuccessFixtureCase>`) drives a **success** response for a method
+whose generated nil ids can only refuse: the factory builds the row, then
+returns `{params, headers?}` — `headers` replaces the picked identity, for a
+row only its owner may act on. The response must be `ok`, not an internal
+failure, and parse against `output`. `cross_backend/rpc_success_fixtures.ts`
+— `create_spine_rpc_success_fixtures({rpc_path?})` builds the map for the
+standard spine methods that act on an existing row (`account_token_revoke`,
+`account_session_revoke`, `invite_delete`, `role_grant_revoke`,
+`role_grant_offer_accept` / `_decline` / `_retract`) from standard RPC
+actions and the builtin `ROLE_ADMIN` only, each factory on fresh accounts
+and calling as one of them, so any consumer mounting
+`create_standard_rpc_actions` can pass it. The fixtures run last on the
+describe's fixture, since they mutate.
+fuz_app wires it through the standard bundle and in the in-process
+`cross_backend/rpc_round_trip_spine.db.test.ts`.
 
 ### `sse_round_trip.ts` — `describe_sse_route_tests`
 
@@ -666,7 +817,12 @@ lifecycle (via `role_grant_offer_create` + `role_grant_offer_accept` +
 `role_grant_revoke` RPC flows — **not** REST, **not** direct
 `query_accept_offer`; see `auth/CLAUDE.md` for
 `role_grant_offer_action_specs.ts` + `role_grant_offer_actions.ts`),
-session / token management, audit log reads (RPC), admin-to-admin
+session / token management, audit log reads (RPC — every row read is
+parsed by `assert_audit_event_metadata`, closed to undeclared keys when the
+fixture asks, and the completeness test drives login, logout, the offer flow,
+grant + revoke, token create, password change, and — each where the surface
+mounts its actions — token revoke, session revoke, invite create + delete and
+`app_settings_update`), admin-to-admin
 isolation, error coverage, response schema validation.
 
 The shared `role_grant_offer_and_accept` helper (`role_grant_helpers.ts`)
@@ -679,6 +835,12 @@ from `db_entities.ts`.
 
 Required options: `{setup_test, surface_source, session_options, rpc_endpoints: RpcEndpointsSuiteOption, roles: RoleSchemaResult, admin_prefix?}`.
 
+fuz_app runs it cross-process through the standard bundle
+and in-process as a consumer wires it
+(`cross_backend/admin_integration_spine.db.test.ts`) — the in-process fixture's
+`create_account` inserts rows directly, writing no `invite_create` or `signup`
+audit row, so the suite expects neither from it.
+
 `rpc_endpoints` is `Array<RpcEndpointSpec> | ((ctx: AppServerContext) => Array<RpcEndpointSpec>)` —
 the same `RpcEndpointsSuiteOption` union every DB-backed suite accepts
 (`integration`, `admin_integration`, `audit_completeness`, `rate_limiting`,
@@ -763,6 +925,12 @@ invokes the right per-test fixture. Consumers wiring the standard surface
 call once instead of seven times; forgetting a suite no longer silently
 loses coverage.
 
+`rpc_success_fixtures`, `rpc_skip_methods` and `rpc_input_overrides`
+forward to the RPC round-trip's `success_fixtures`, `skip_methods` and
+`input_overrides` (same options on `describe_standard_cross_process_tests`)
+— `rpc_skip_methods` is the consumer escape hatch for a method the generic
+round-trip can't drive in its test wiring.
+
 `StandardTestOptions` requires `create_route_specs` (for rate_limiting) and
 `rpc_endpoints` (for admin/audit_completeness/rpc_round_trip); the admin
 suite's requirement is enforced at the type level so a missing
@@ -810,6 +978,7 @@ One-shot transport:
 - `RpcCallResult` — discriminated `{ok: true, status, headers, result}` / `{ok: false, status, headers, error: {code, message, data?}}`. `headers` is the lowercased-key response-header snapshot so callers can assert header-level properties (e.g. the conformance runner's no-fingerprint invariant).
 - `headers_to_record(headers)` — snapshot a `Headers` into a lowercased-key `Record<string, string>` (multi-value collapses to the comma-joined form; `Set-Cookie` excluded). Used by `rpc_call` and the conformance table's REST branch to thread response headers through for assertions.
 - `RpcCallArgs` — `{app, path, method, params?, headers?, id?, verb?}`. `verb` defaults to `'POST'`; use `'GET'` for `side_effects: false` methods.
+- `rpc_call_raw(args)` — the same request as `rpc_call`, the response unparsed: `RpcCallRawResult` `{status, headers, body}` with the whole envelope. `parse_rpc_call_result(raw, method)` turns it into an `RpcCallResult`; `rpc_call` is the two composed.
 - `rpc_call(args)` — merges `RPC_CALL_DEFAULT_HEADERS` (`host: 'localhost'`, `origin: 'http://localhost:5173'`, `Content-Type: 'application/json'`) under caller headers. Envelope-shape violations throw; JSON-RPC errors return `{ok: false, error}` so callers assert on `error.code` / `error.data.reason`.
 - `rpc_call_typed<T>(args, output_schema)` — parses the success `result` through the schema; throws on envelope failure, error response, or schema mismatch. Use `rpc_call` when the test needs to assert on error shapes.
 - `rpc_call_for_spec<TSpec>(args)` — spec-bound variant: takes `{..., spec, params}` in place of `{..., method, params}`. `params` is typed from `spec.input` and the success `result` is typed from `spec.output` (runtime-validated, same contract as `rpc_call_typed`). Error branch stays untyped (JSON-RPC `error.data` shapes vary per call site). Use at happy-path + denial-path call sites; fall back to `rpc_call` for adversarial tests that send deliberately-malformed params.
@@ -822,7 +991,7 @@ Registry lookups:
 - `RpcEndpointsSuiteOption` — union `Array<RpcEndpointSpec> | ((ctx: AppServerContext) => Array<RpcEndpointSpec>)` accepted by every DB-backed suite's `rpc_endpoints` field.
 - `resolve_rpc_endpoints_for_setup(rpc_endpoints, session_options)` — resolves the union to an array for setup-time inspection (path lookup, `find_rpc_action` presence checks). Factory form is invoked once with a stub `AppServerContext`; the produced actions are discarded because `create_app_server` invokes the factory a second time per-test with its real ctx. Safe when the factory is pure wrt endpoint `path` and action `spec.method` list.
 
-### `rpc_attack_surface.ts` — `describe_rpc_attack_surface_tests`
+### `rpc_attack_surface.ts` + `rpc_envelope_cases.ts` — `describe_rpc_attack_surface_tests`
 
 3 test groups for JSON-RPC endpoints:
 
@@ -833,8 +1002,8 @@ Registry lookups:
    - **keeper rejects non-daemon credentials** — session and api_token credentials are rejected even when the account has the keeper role (only `daemon_token` passes). The credential-type gate fires before the role gate (see `auth/CLAUDE.md` §Keeper auth shape).
    - correct auth passes (not 401/403)
    - GET unauthenticated for `side_effects: false` reads
-2. **RPC adversarial envelopes** — fixed set exercising dispatcher steps 1–2: non-JSON body, wrong `jsonrpc` version, missing `jsonrpc` / `method` / `id`, batch array, unknown method, GET missing `method`/`id`, GET invalid JSON params, GET non-object params, GET mutation method → `invalid_request`.
-3. **RPC adversarial params** — reuses `generate_input_test_cases` but filters out structural cases (those hit envelope validation at step 1, not params validation at step 5). Every case expects 400 `invalid_params`.
+2. **RPC adversarial envelopes** — the fixed set `create_rpc_envelope_cases(endpoint, {skip_methods?})` builds, exercising the envelope parse, method lookup, and GET read restriction: non-JSON body → `parse_error`, wrong `jsonrpc` version, missing `jsonrpc` / `method` / `id`, batch array, non-object POST `params` → `invalid_request`, unknown method → `method_not_found`, GET missing `method`/`id` → `invalid_request`, GET invalid-JSON params → `invalid_params`, GET non-object params on **every** read (each of `RPC_NON_OBJECT_PARAMS`: a number, an array, a string, a boolean) → `invalid_params`, GET mutation method → `invalid_request`, plus three ordering cases sent with no credential (an anonymous GET mutation and an anonymous batch, both `invalid_request`, never 401; an anonymous GET with non-object params on a read requiring an identity, the 401 — params validation runs after authorization). Each case is sent by the app its method's auth admits (`select_auth_app`) and pins status, code, echoed `id`, and `data.reason` (exact where the dispatcher sets one, absent otherwise) via `assert_rpc_envelope_refusal`. The cases are data (`RpcEnvelopeCase`) in the hono-free `rpc_envelope_cases.ts`, shared with the cross-process `describe_rpc_adversarial_cross_tests`; `to_rpc_envelope_request` builds a case's request, and `rpc_get_side_effects_reason(method)` is the GET read restriction's reason.
+3. **RPC adversarial params** — `generate_rpc_params_test_cases(input)` (`rpc_envelope_cases.ts`): `generate_input_test_cases` minus its structural cases (a non-object `params` is refused at the envelope, not at params validation). Every case expects 400 `invalid_params`. Shared with the cross-process suite.
 
 Skips silently when `surface.rpc_endpoints` is empty. Uses stub deps — no
 DB needed.
@@ -874,10 +1043,17 @@ test-server core below (fuz_app's own domain-free `testing_spine_server`, run
 on Node + Deno + Bun). In-process is the fast feedback path; cross-process is the
 source of truth for wire-shape conformance.
 
+fuz_app's own spines run every single-backend suite below through one
+`describe_spine_cross_suites` call, `src/test/cross_backend/spine_suites.cross.test.ts`
+(§`cross_backend/spine_suites.ts`), so a suite's section names the suite, not a
+file; the dual-spawn and limiter-enabled suites name their own files.
+
 ### Fixture protocol + capabilities
 
 - `testing/cross_backend/setup.ts` — `SetupTest` / `TestFixture` /
-  `TestAccountFixture` / `CreateTestAccountOptions` types,
+  `CreateTestAccountOptions` types (`fixture.create_account` and
+  `fixture.extra_accounts` hand out `TestAccount`s from `app_server.ts`, built
+  by `to_test_account`),
   `default_in_process_setup(options)` (wraps `create_test_app`; pass
   `migration_namespaces` for suites needing tables beyond the auth-only
   default — the cell parity suite passes `[CELL_MIGRATION_NS]`, and
@@ -913,7 +1089,11 @@ source of truth for wire-shape conformance.
   lands with an email set — the hook the username-or-email login parity suite
   uses; the in-process path sets it directly on the inserted row. Must be a
   valid, per-test-unique `Email` (the `LOWER(email)` partial-unique index
-  rejects collisions). Caller-supplied `username`s pass through _as-is_ now that the DB
+  rejects collisions). The signup and login it drives go to the setup's
+  `signup_path` / `login_path` (default `SPINE_ACCOUNT_SIGNUP_PATH` /
+  `SPINE_ACCOUNT_LOGIN_PATH`, from `spine_surface_constants.ts`, which also
+  carries the other account routes, `SPINE_WS_PATH`, and the prefix).
+  Caller-supplied `username`s pass through _as-is_ now that the DB
   wipes between tests — hardcoded names like `'user_two'` work and the
   earlier uniquification prefix is gone. Every `TestFixture` also exposes
   `fresh_transport({origin?: string | null})` — cookie-jar-free probe;
@@ -930,22 +1110,31 @@ source of truth for wire-shape conformance.
 
 - `testing/cross_backend/capabilities.ts` — `BackendCapabilities` vocabulary
   (the **gating** flags `ws` / `sse` / `cell_crud` / `cell_relations` /
-  `cell_gated_create` / `account_lifecycle` / `fact_serving` / `ready` /
+  `cell_gated_create` / `account_lifecycle` / `fact_serving` /
+  `fact_serving_admin_hash` / `ready` /
   `account_status` / `peer_request` /
   `ws_handshake_pipelining` / `ws_account_actions` /
   `ws_role_gated` / `ws_refusal_body` — each has a `test_if`
   reader (`ws_refusal_body` picks how the front-door table reads a WS
   refusal instead); `peer_request` (server-initiated requests — the ActionPeer
-  `peer/ping` round-trip) is `true` for both the Rust spine and the TS spine
-  (`BackendWebsocketTransport.request_connection`); `ts_default_capabilities`
-  keeps it `false` like sse/ready until a backend wires the `peer/ping` HTTP +
-  WS mount), `test_if(cond, name, fn)`
-  for capability-gated cases, and `in_process_capabilities` preset. The
-  non-gating wiring facts (`bearer_auth` / `trusted_proxy` / `login_rate_limit`,
-  no `test_if` readers) live in the parallel `BackendShapeNotes` record
-  (`in_process_shape_notes`; `ts_default_shape_notes` / `rust_default_shape_notes`
-  in `default_backend_configs.ts`) — split out so the capability type stops
-  claiming gating it doesn't do. `cell_crud`
+  `peer/ping` round-trip) is `true` on fuz_app's Rust and TS spine presets
+  (`BackendWebsocketTransport.request_connection`); a backend states it
+  `true` once it wires the `peer/ping` HTTP + WS mount), `test_if(cond, name, fn)`
+  for capability-gated cases, and `in_process_capabilities` preset. Only
+  flags a suite reads are capabilities — a wiring fact that gates nothing is
+  not recorded. **Mount flags have no family default**: `MountFlag` names the
+  flags that describe a backend's own mounts (`ws`, `sse`, `cell_crud`,
+  `cell_relations`, `cell_gated_create`, `fact_serving`,
+  `fact_serving_admin_hash`, `ready`,
+  `peer_request`, `ws_account_actions`, `ws_role_gated`), and the family
+  defaults (`ts_default_capabilities` / `rust_default_capabilities`, typed
+  `FamilyDefaultCapabilities`) omit them, with `capabilities` required on
+  `make_default_{ts,rust}_backend_config` — so a config that leaves one out
+  fails typecheck naming it, rather than silently skipping its suites. The
+  family defaults carry the declared surface's mounts (`account_lifecycle`,
+  `account_status`) and the runtime-behavior flags (`ws_handshake_pipelining`,
+  `ws_refusal_body`) of the family's reference runtime — Node for TS, hyper
+  for Rust; a backend on another runtime (Deno, Bun) overrides them. `cell_crud`
   gates the CRUD parity suite, `cell_relations` the relation / ACL / audit
   parity suite — both `true` on every backend that live-mounts the full cell
   surface (TS spine binary, in-process app, Rust stub). A backend mounting only
@@ -965,15 +1154,19 @@ source of truth for wire-shape conformance.
   auto-enumerated for shape/auth) — the flag gates the behavioral parity the
   generic round-trip can't drive (it can't delete the subject). `true` on every
   spine. `fact_serving`
-  gates `describe_fact_serving_cross_tests` (the cell-scoped per-reference +
-  admin-only bare-hash fact-serving parity suite, incl. the served fact's
-  hardening headers and bodyless masked 404s); like cells it stays off the
-  declared surface and is `true` on every spine that mounts the serve routes +
+  gates `describe_fact_serving_cross_tests` (the cell-scoped per-reference
+  fact-serving parity suite, incl. the served fact's hardening headers and
+  bodyless masked 404s); like cells it stays off the declared surface and is
+  `true` on every spine that mounts the cell-gated serve route +
   the `_testing_put_fact` seeder (whose optional `holder` records a
   `fact_holder` row, so a non-admin can reference what it seeds, and whose
   optional `external_url` writes a bare external row naming that URL, so the
   suite can pin that a URL naming another hash's file is refused) — it also
-  gates `describe_cell_ref_admission_cross_tests`. `ready` gates `describe_ready_cross_tests`
+  gates `describe_cell_ref_admission_cross_tests`. `fact_serving_admin_hash`
+  is the admin-only bare-hash route (`GET /api/facts/:hash`), its own flag
+  because a backend can serve the cell-gated route alone: it gates the
+  fact-serving suite's bare-hash cases (with `fact_serving`) and the bare-hash
+  cases of the query-shape and token-scope-surface suites. `ready` gates `describe_ready_cross_tests`
   (anonymous `GET /ready` → `200 {ready: true}` on a clean spine bootstrap);
   like cells/sse the `/ready` deploy gate stays off the declared surface, `true`
   on every spine that live-mounts it over the shared `expected_schema.json`.
@@ -993,7 +1186,7 @@ source of truth for wire-shape conformance.
   as it does behind auth, and `false` in-process, where there is no socket to
   write raw bytes to).
   `ws_account_actions` (the WS endpoint mounts the account actions — `true` on
-  fuz_app's own spine presets, `false` in the family defaults) gates the WS
+  fuz_app's own spine presets; a consumer states it like every mount flag) gates the WS
   round-trip suite's self-revocation case (which requires the reply ahead of
   the close on every backend) and, with `rpc_path`, its WS-mutation audit case
   (which calls `_testing_drain_effects`).
@@ -1026,6 +1219,129 @@ consumer needs partial opt-out, add the knob then.
 `bootstrap`, `rate_limiting_app_options`, `bootstrap_token`) — those drive
 the omitted suites.
 
+### `cross_backend/spine_suites.ts` — `describe_spine_cross_suites`
+
+One call that runs every shipped single-backend cross suite against one
+spawned backend: `describe_spine_cross_suites(handle, {surface_source,
+session_options, rpc_endpoints, live_rpc_endpoints?, roles?, setup?, exclude?,
+overrides?, rpc_success_fixtures?, rpc_skip_methods?, rpc_input_overrides?,
+rpc_max_body_bytes?, ws_max_message_bytes?})`.
+`live_rpc_endpoints` is the backend's whole live mount; given, `rpc_adversarial`
+also walks the methods it keeps off the declared surface. Without it a
+consumer writes a file per suite, and a suite added here never reaches it.
+
+- **The registry.** `SUITE_NAMES` / `SuiteName` — the closed set of suites the
+  call runs, each named by its module (`ws_round_trip` is
+  `describe_cross_process_ws_tests`, `standard` the standard bundle).
+  `STANDALONE_CROSS_SUITES` (keyed by the closed `StandaloneSuiteName`) names
+  the modules left out, each with why: the
+  `differential` (two handles), `login_security` and `ws_action_rate_limit`
+  (a backend spawned with live limiters, which the standard suites would
+  exhaust), and the `conformance_table` runner (the consumer's own cases).
+  `src/test/testing/cross_backend/spine_suites.test.ts` imports every module
+  under `cross_backend/` and holds the two lists to the ones exporting a
+  `describe_*` function, whatever the export form (the Bun and Deno adapters,
+  which load only on their own runtime, are held to naming no `describe_` at
+  all), so a new suite fails until it is registered or stated standalone; the
+  dispatch table
+  is a `Record<SuiteName, …>`, so a registered name without an entry fails
+  typecheck.
+- **Options from the handle.** Paths, cookie name and capabilities come from
+  `handle.config` — `to_cross_suite_options(handle)`, exported for a suite
+  called on its own — the daemon token from the handle, and each suite's
+  `setup_test` from `default_cross_process_setup` over the `setup` options
+  plus the seeding the suite needs (concatenated): a keeper-only
+  `non_admin_keeper` for the standard bundle's keeper ≠ admin probe, the
+  multi-actor keepers of `fact_serving` and `transport_composition`, the
+  offer grantor of `role_grant_offer_enumeration`, the `cell_editor` holder of
+  `cell_grant_role`. Suites are registered without a wrapping `describe`, so
+  test names match a standalone call.
+- **`ws_required_roles`** — the roles the backend's WS upgrade on `ws_path`
+  requires (an admin-gated `/api/ws`: `[ROLE_ADMIN]`). The suites that open
+  sockets for accounts they create (`credential_deadline`, `session_cap`,
+  `ws_round_trip`) create them holding these (`ws_account_roles`), and
+  `role_grant_offer_notification_ws` expects revoking one to close the socket
+  (its `ws_required_roles`) — one option for every socket a role gates.
+- **`rpc_max_body_bytes`** / **`ws_max_message_bytes`** — the backend's
+  request-body cap on `rpc_path` and its inbound WS message cap, when they
+  aren't the spine defaults (`SPINE_BODY_LIMIT_DEFAULT_BYTES`,
+  `DEFAULT_WS_MAX_MESSAGE_BYTES`). The first reaches `body_size`,
+  `body_size_smuggling` and `transport_composition`'s RPC over-cap row (each
+  takes it as `rpc_max_body_bytes`), the second `ws_round_trip`'s
+  `max_message_bytes` — one value per limit for every suite probing it.
+- **`exclude`** — `{[suite]: reason}`; the reason is required and shows in the
+  run as a skipped test. An empty reason, an unknown suite name, or a suite
+  both excluded and overridden throws before anything registers.
+- **`overrides`** — `SuiteOverrides`, per suite a `Partial` of its own options
+  (`SuiteOptionsMap`), shallow-merged over the derived ones: a role list, an
+  `xfail`, a narrower capability set, `ws: undefined` to drop optional socket
+  cases (`session_cap` and `testing_backdoor` take no `capabilities`, so `ws` is
+  their only socket switch). An entry can instead be a function of the derived
+  options returning the patch (`SuiteOverride`), for a change built on a
+  derived value — an `xfail` added to the derived multi-actor setup — so the
+  seeding isn't restated. After the merge, every option the suite's type
+  requires (each entry's `required` set, exhaustive by type) must be neither
+  `undefined` nor `''`, or the call throws at collection naming suite and key.
+- **Inputs the handle doesn't carry.** The declared surface is a required
+  option. Paths and roles that name the reference spines' mounts (the
+  role-gated WS endpoint and its roles) default to the `SPINE_*` constants —
+  a suite whose flag is off never reads them, and a backend mounting its own
+  overrides them. Anything else comes from the config when it can
+  (`session_cookie_codec`'s `cookie_keys` from `SECRET_FUZ_COOKIE_KEYS`), else
+  from `overrides`; with neither, the call throws naming the suite and the
+  field — provide it or exclude the suite.
+
+Each suite reads its own capability flags, so a backend's truthful
+`BackendConfig.capabilities` decides what runs. The role-shaped suites default
+to the spine's own roles — `cell_grant_role`'s `cell_editor`, the
+`participant` `role_grant_offer_lifecycle` offers and
+`role_grant_participation` confers — and take another through `suite_roles`
+(`SpineSuiteRoles`: `cell_grant`, `conferral`), which the call also seeds on
+the holder each needs (set it there, not in `overrides`, which would leave the
+seed on the default). A backend with only the builtin roles passes
+`{cell_grant: ROLE_KEEPER, conferral: ROLE_ADMIN}`: keeper reach is not admin
+reach, so every `cell_grant_role` arm still turns on the grant, while an admin
+views and edits every cell — `describe_cell_grant_role_cross_tests` refuses
+`ROLE_ADMIN` — and the scoped-assign case of `role_grant_participation` skips
+for a builtin. fuz_app's own wiring is
+`src/test/cross_backend/spine_suites.cross.test.ts`.
+
+### `cross_backend/rust_spine_consumer_surface.ts` — `create_rust_spine_consumer_surface_spec`
+
+The declared surface of a consumer served by the Rust spine, for its cross
+suites: `create_rust_spine_consumer_surface_spec({session_options,
+domain_action_specs, extra_rpc_actions?, roles?, exclude_methods?,
+rpc_path?, host_gate?})`, built on `create_test_app_surface_spec` from the hono-free route
+shapes. It declares `/health`, the `ACCOUNT_ROUTER_PATHS` under
+`/api/account` (`/status`, `/login`, `/logout`, `/password` — what
+`fuz_auth::account_router` mounts, so the TS-only `/verify` stays off), signup,
+bootstrap as a `surface_only` shape, the daemon-token layer the consumer test
+binaries wire, a `host_validation` stub layer at the head of the middleware
+list when `host_gate` says the server turns on the spine's opt-in host gate
+(default off), and one RPC endpoint: the standard actions (over `roles`), the
+`extra_rpc_actions` (opt-in families built against the stub context), then the
+request-response, non-protocol `domain_action_specs` minus `exclude_methods`
+(methods the spec-derived suites can't drive; an entry naming no domain spec
+throws). `create_rust_spine_consumer_rpc_endpoints(options)` is that endpoint
+alone, for `describe_spine_cross_suites`'s `rpc_endpoints`. Handlers are
+no-ops — live dispatch happens in the spawned binary. A server mounting no
+signup router (a single-keeper daemon) is not this shape.
+
+### `cross_backend/provided_context.ts` — `inject_backend_handle`
+
+Augments vitest's `ProvidedContext` with the keys the shipped global setups
+provide — `backend_handle` (`create_cross_backend_global_setup`) and
+`parity_handle_a` / `parity_handle_b` (`create_dual_spawn_global_setup`'s
+default keys) — and reads them: `inject_backend_handle()` /
+`inject_parity_handles()` return the handles rebuilt by
+`reconstruct_bootstrapped_handle`. The augmentation ships in the module's
+`.d.ts`, so a test file importing either helper gets the typed `inject` with
+no augmentation of its own — a type-only import of the module carries it too,
+and a global setup built on the shipped makers needs none. A project providing other
+keys — a dual spawn under its own `provide_keys`, a probe result — augments
+`ProvidedContext` for those itself; fuz_app's are in
+`src/test/cross_backend/cross_test_types.ts`.
+
 ### `cross_backend/conformance_table.ts` + `conformance_case.ts` + `xfail.ts` — declarative behavioral/security cases
 
 The opinionated behavioral/security layer on top of the spec-derived
@@ -1036,7 +1352,7 @@ conformance cases assert _expected behavior_ — the security negatives
 wire-shape check passes green on even when behavior is wrong.
 
 - `conformance_case.ts` — `ConformanceCase` Zod schema:
-  `{name, request: {method, params?, as, verb?}, expect: {status,
+  `{name, request: {method, params?, as, acting?, verb?}, expect: {status,
 error_reason?, fields?, headers?, equivalence_group?}, note?, xfail?}`. A case is **data** — `method`
   resolves its `input`/`output` from the live registry (RPC) or `RouteSpec`
   (the 6 REST auth routes), so the case never carries a schema. `as` is the
@@ -1069,10 +1385,17 @@ error_reason?, fields?, headers?, equivalence_group?}, note?, xfail?}`. A case i
   `expired_session` is the keeper behind an expired server-side session
   (`fixture.mint_expired_session()`: a backdated `auth_session` row behind a
   still-valid signed cookie, so the DB-row expiry gate is what refuses it).
+  `acting` (`ConformanceActingBinding`) has the runner fill `params.acting`
+  with a real actor id: `principal` (the actor of the account the
+  principal's credential names), `extra_actor` (`fixture.extra_actors[0]`),
+  `keeper_actor` (`fixture.actor`, foreign to every non-keeper principal);
+  params must then be an object or omitted, without an `acting` of their own,
+  and a principal presenting no account throws.
   `error_reason` is the imported
   `ERROR_*` constant (asserted against the RPC `error.data.reason` or the
-  REST flat-body `error`; the bare `unauthenticated()` 401 carries no
-  reason, so `status` pins that denial class). `equivalence_group` is the
+  REST flat-body `error`; the dispatcher's 401 carries
+  `authentication_required`, and a denial with no reason — a handler's bare
+  `forbidden` — is pinned by `status`). `equivalence_group` is the
   **negative-space** axis: every case tagged with the same group string must
   produce a **byte-identical** normalized response (`{status, body}`),
   asserted per impl after the case loop. It promotes a masked pair
@@ -1091,14 +1414,76 @@ error_reason?, fields?, headers?, equivalence_group?}, note?, xfail?}`. A case i
   backend-fingerprinting oracle). Headers are deliberately kept out of the
   `equivalence_group` `{status, body}` comparison (`Set-Cookie` / `Date` vary).
 - `conformance_table.ts` — `describe_conformance_table_tests({cases,
-setup_test, surface_source, capabilities, rpc_endpoints, session_options,
-principals?, suite_name?})`. Same `{setup_test, surface_source,
+setup_test, surface_source, capabilities, rpc_endpoints, live_rpc_endpoints?,
+session_options, principals?, ws?, suite_name?})`. A case's RPC method
+  resolves from `rpc_endpoints` first, then from `live_rpc_endpoints` — the
+  endpoints the backend live-mounts, for methods kept off the declared surface
+  (cell verbs, opt-in resolvers, `_testing_*` backdoors); a backend's whole
+  live mount is a fine value, since a declared method still resolves from the
+  declared surface. `resolve_conformance_rpc_endpoints({rpc_endpoints,
+  live_rpc_endpoints?, session_options})` (exported) builds that lookup list,
+  for the table and the differential alike. fuz_app's spine value is
+  `create_spine_live_rpc_endpoints()` (`full_spine_mount.ts`), the binary's
+  whole mount built on stub deps for resolution only. Same `{setup_test, surface_source,
 capabilities}` protocol every Tier 1 suite uses, so **one case array runs
   both transports** — in-process (`gro test`) and cross-process (the gate,
-  each backend's real auth resolution). `resolve_principal` maps the five
+  each backend's real auth resolution). `resolve_conformance_principal` (exported) maps the five
   always-available principals to fixture accessors; `role_holder` /
   `wrong_role` read a seeded `extra_accounts` username named via
-  `options.principals`.
+  `options.principals`. `send_conformance_case(c, {fixture, surface_source, principals?,
+  resolved_rpc_endpoints})` (exported) is the send half — principal resolved,
+  request sent, the raw `{target, status, headers, body}` back unasserted; the
+  table asserts on it, and the cross-backend differential compares two.
+  **WS leg:** `ws: WsEndpointTarget` (`{base_url, ws_path, origin?}`) on
+  either sends each case as one frame on an admitted socket the principal
+  opens — its headers on the upgrade, no `Origin` where the HTTP leg
+  suppresses it, its own actor as `?acting=`. Only the TS spine resolves an
+  actor at the upgrade, refusing a multi-actor account's upgrade without
+  `?acting=` (400 `actor_required`); the Rust spine's upgrade resolves the
+  account and ignores it. Per-frame dispatch resolves each frame's `acting` on
+  both. The leg always sends `?acting=`, so it does not cover that
+  upgrade-level difference; the front-door table's multi-actor row does. The frame is the envelope the HTTP
+  body is (`perform_action_result_to_envelope` on TS), so the response reads
+  `{status, headers: {}, body: frame}` with `status` the code's
+  `jsonrpc_error_code_to_http_status` (200 for a result) and every row holds
+  unchanged. What WS loses is headers — the TS DEV-only `X-Fuz-Auth-Debug`
+  among them. `is_ws_conformance_case(c)` (exported) is the filter: RPC, sent
+  `POST`, no header value pinned, a principal that can hold a socket — not
+  `anonymous` / `bearer_browser` / `malformed_bearer` / `expired_session`,
+  refused at the upgrade, nor `scoped_token`, refused `surface:ws_upgrade`
+  there (a narrowed bearer can never send a frame, so no per-frame scope row
+  exists; the front-door table pins the upgrade refusal). An equivalence
+  group left with one member on the WS leg is dropped. Cross-process only.
+- `conformance_rpc_auth.ts` — `generate_rpc_auth_conformance_cases({surface_source,
+  live_rpc_endpoints?, skip_methods?})` → `ConformanceCase[]` from each declared RPC method's
+  `RouteAuth`, then each live-mounted one the declared surface lacks
+  (`live_rpc_endpoints`, resolved — the rows then need the same endpoints on
+  the runner's `live_rpc_endpoints`): `anonymous` → 401 `authentication_required` for every method
+  needing an account or actor (all in the
+  `RPC_AUTH_ANONYMOUS_EQUIVALENCE_GROUP`, since the 401 must not vary by
+  method); for a `credential_types` gate, each builtin channel it refuses
+  (`keeper` = session, `token` = api_token, `daemon` = daemon_token, each the
+  keeper) → 403 `credential_type_required` with `required_credential_types`;
+  for `roles` on a method admitting a session, `fresh_non_admin` → 403
+  `insufficient_permissions` with `required_roles`; public methods get
+  nothing. Params are `generate_valid_body` minus its generated `acting`
+  (read before validation, so the generator's id would answer
+  `actor_not_on_account`), so a missing gate reaches the handler rather than
+  a 400. On an actor-bound method the credential and role rows bind
+  `acting: 'principal'` instead — both spines resolve the acting actor before
+  the credential gate, so a keeper with a second actor (`extra_actors`) would
+  otherwise answer `actor_required` — and the rows hold for a single-actor and
+  a multi-actor keeper alike. The rows pin each
+  gate, not its order against validation (the security slate's
+  401-before-400 rows do). Skips `PROTOCOL_ACTION_METHODS` (fixed shared specs,
+  WS-scoped — `cancel` has no reply, `peer/ping` is public — and covered by
+  the WS suites). Given the live mount, the `_testing_*` backdoors get rows too:
+  each is daemon-token-gated, so anonymous → 401 and the keeper's session and
+  API token → 403 `credential_type_required`. Exists
+  because the action-manifest parity gate compares declarations, not the
+  live gates, and the Rust spine dispatches its own. Input-dependent handler
+  checks stay hand-written rows. fuz_app spreads it into both conformance
+  legs.
 - `xfail.ts` — `xfail_until(tracking_id, reason, name, fn)`, a thin
   `test.fails` wrapper for deferred-by-design rows (visible + self-cleaning:
   turns red when the gap closes, forcing marker removal). In-scope gaps fail
@@ -1108,7 +1493,36 @@ capabilities}` protocol every Tier 1 suite uses, so **one case array runs
 Wire from a `.db.test.ts` (in-process) and a `.cross.test.ts`
 (cross-process) with the same case array — fuz_app's own runner-proof is
 `../../test/cross_backend/conformance.{db,cross}.test.ts` sharing
-`conformance_proof_cases.ts`.
+`conformance_proof_cases.ts`, the generated auth rows, and
+`conformance_admin_cases.ts` (offer list/history across accounts, invite
+errors, pagination bounds on the admin lists); two checks the table can't
+express ride beside it on both legs: the duplicate-invite refusal (two
+requests, `describe_invite_duplicate_tests` in `invite_duplicate.ts`) and the
+offer reads' cross-account refusal being identical for the keeper's real id
+and the nil id (`describe_offer_cross_account_tests` in
+`offer_cross_account.ts` — the existing id is known only to the fixture).
+The cross legs pass the spine's live mount, so the table also runs
+`conformance_actor_cases.ts` (`actor_lookup`'s empty-`ids` bound, the
+`actor_search` scope gate) and `conformance_cell_cases.ts` (the cell refusals
+one request reaches with no cell in place: `kind` inside `data`, `cell_get`
+naming neither `id` nor `path`, the relation lists naming neither or both
+endpoints — each `invalid_params` with its declared reason — a grant miss
+`cell_grant_not_found`, the `cell_list` pagination bounds and enum-valued
+filters, and the schema-first rows where a bad page or filter value must answer
+before a handler's reason; `conformance_cell_cases.test.ts` requires a `{}` row
+with a reason for every cell action whose input is marked
+`empty_input_handler_guarded`), with the
+generated rows over the off-surface methods; the in-process leg for those is
+`conformance_off_surface.db.test.ts`, over an app mounting the cell surface
+and the two resolvers. The cross leg runs the same cases
+over WS too, and both legs run `conformance_acting_cases.ts` with the
+generated rows on a keeper seeded with `extra_actors`: no `acting` or a
+malformed one → 400 `actor_required`; the nil id, an unused id and another
+account's real actor → one identical 400 `actor_not_on_account`; acting as
+the extra actor (no grants) → 403 `insufficient_permissions` on an admin
+method over a session and a bearer, and on the keeper-gated `account_purge`
+over the daemon token; acting as the bootstrap actor passes the same gates.
+The role gate reads the resolved actor's grants on both spines.
 
 ### `cross_backend/ws_round_trip.ts` — `describe_cross_process_ws_tests`
 
@@ -1119,7 +1533,7 @@ needs raw `base_url` / `ws_path` the standard bundle doesn't carry, mirroring
 how `describe_ws_round_trip_tests` sits beside `describe_standard_tests`
 in-process. `describe_cross_process_ws_tests({setup_test, capabilities,
 base_url, ws_path, origin?, rpc_path?, max_message_bytes?, logout_path?,
-password_path?, max_tokens?})` opens a live
+password_path?, max_tokens?, ws_account_roles?})` opens a live
 `WebSocket` via `create_ws_transport` (the `ws` npm package) and asserts
 cases against the upgrade stack `register_ws_endpoint` wires (origin →
 `require_auth` → dispatch): authed upgrade round-trips `heartbeat`,
@@ -1149,7 +1563,9 @@ bearer socket (a socket on its other token stays open);
 bearer socket of the token the cap evicts. The account-wide rows come from
 `cross_backend/revocation_drivers.ts` (`create_account_revocations`, shared
 with the SSE suite), and a case that opens several sockets closes whichever
-opened when a later open fails. Per-connection auth is enforced **at upgrade
+opened when a later open fails. The second accounts are created holding
+`ws_account_roles`, for a backend whose WS upgrade requires a role (an
+admin-gated `/api/ws` refuses a roleless account). Per-connection auth is enforced **at upgrade
 time**, so the negative upgrade cases assert the upgrade itself rejects, not
 a per-message error; the close cases prove a revocation closes an
 already-open socket, since per-message dispatch never re-checks credential
@@ -1168,7 +1584,7 @@ so it validates the transport without touching domain WS methods. Gated on
 `capabilities.ws`; cross-process only (needs a real bound socket — wire from
 a `*.cross.test.ts`, never an in-process setup). Authed cookies come from the
 fresh-per-test keeper via `fixture.transport.cookies()`, not the stale
-globalSetup handle. fuz_app's own wiring is `src/test/cross_backend/ws.cross.test.ts`.
+globalSetup handle.
 
 ### `cross_backend/role_grant_offer_notification_ws.ts` — `describe_role_grant_offer_notification_ws_tests`
 
@@ -1185,7 +1601,23 @@ lifecycle RPC over `fixture.transport`, then
 strict-parses the delivered frame against its canonical params schema from
 `auth/role_grant_offer_notifications.ts` (the guard against serialization drift —
 field / null / datetime / the flat revoke shape / the supersede `reason` +
-`cause_id`). Unlike `describe_cross_process_ws_tests` (consumer-agnostic,
+`cause_id`). Every case also opens a **bystander** — a third account's
+admitted socket, party to nothing the case drives — and once the targeted
+frame has landed sends a `heartbeat` on it and asserts it received nothing
+but the answers to its own requests. The barrier is what makes the silence
+mean something: both spines queue a fan-out to every recipient in one pass
+with no await in it, and neither writes a response ahead of a notification
+already queued for the same connection — the TS transport sends both through
+one outbound queue, and the Rust loop writes a connection's queued frames
+before a response (`flush_queued_frames`). So a frame the pass addressed to
+the bystander reaches it ahead of the barrier's response. That is strict on TS,
+which sends a fan-out in one synchronous closure. On Rust, `deliver_all` pushes
+to recipients one after another on one worker while the target's connection
+loop runs on another, so the target's frame can be written while the pass is
+still pushing — a window the barrier's round trip outlasts in practice. The
+check covers every pass of the drain: the Rust `PostCommitEffects::drain_all`
+joins effects whose notify futures push synchronously, so every pass
+completes in the drain's first poll. Unlike `describe_cross_process_ws_tests` (consumer-agnostic,
 `heartbeat`-only), this drives a real **domain** notification family — but one
 built from spine primitives only (accounts / role-grants / offers / WS), zero
 consumer domain, so it lives here and runs against any backend that wires the
@@ -1204,8 +1636,7 @@ grant and expects its socket to close with `WS_CLOSE_PERMISSION_REVOKED` (the
 notification may or may not land first, and is held to the flat shape when it
 does), where an ungated socket expects the frame. The offer/accept fixtures are `create_pending_role_grant_offer` /
 `create_active_role_grant` (`cross_backend/role_grant_cross_helpers.ts`).
-Gated on `capabilities.ws`; cross-process only. fuz_app's own wiring is
-`src/test/cross_backend/role_grant_offer_notification_ws.cross.test.ts`, and
+Gated on `capabilities.ws`; cross-process only. fuz_app's
 `role_grant_offer_notification_ws_gated.cross.test.ts` runs it again over the
 spine binaries' role-gated endpoint with `ws_required_roles` declared.
 
@@ -1227,7 +1658,6 @@ must hold `ROLE_ADMIN` and `scoped_role` (a role an admin can grant scoped).
 fuz_app's spine binaries mount `SPINE_ROLE_GATED_WS_PATH` gated on
 `SPINE_ROLE_GATED_WS_ROLES` (`admin` + `participant`). Gated on
 `capabilities.ws` and `capabilities.ws_role_gated`; cross-process only.
-fuz_app's own wiring is `src/test/cross_backend/ws_role_gated.cross.test.ts`.
 
 ### `cross_backend/peer_ping_ws.ts` — `describe_peer_ping_ws_tests`
 
@@ -1251,8 +1681,7 @@ the HTTP no-transport path. Gated on `capabilities.peer_request` — `true` on
 both the Rust spine and the TS spine (the `BackendWebsocketTransport.request_connection`
 path + `register_action_ws` response correlation); `peer/ping` is a protocol
 action (manifest-excluded), so parity is behavioral here, not via the manifest
-gate. Cross-process only; fuz_app's own wiring is
-`src/test/cross_backend/peer_ping_ws.cross.test.ts`.
+gate. Cross-process only.
 
 ### `cross_backend/ws_inbound_dispatch.ts` — `describe_ws_inbound_dispatch_cross_tests`
 
@@ -1267,8 +1696,7 @@ client's responder withholds the server's ping echo until the test releases
 it — so the suite gates on `capabilities.peer_request`.
 `describe_ws_inbound_dispatch_cross_tests({setup_test, capabilities, base_url,
 ws_path})`. The wire literals are independent copies of the producers'
-constants, so a value changed on one spine fails here. Cross-process only;
-fuz_app's own wiring is `src/test/cross_backend/ws_inbound_dispatch.cross.test.ts`.
+constants, so a value changed on one spine fails here. Cross-process only.
 
 ### `cross_backend/ws_outbound_overflow.ts` — `describe_ws_outbound_overflow_cross_tests`
 
@@ -1297,8 +1725,7 @@ flood action is daemon-token-gated, so the flooding socket upgrades with the
 daemon token and no `Origin` (`create_ws_transport`'s `origin: null`). The wire
 literals are independent copies of the producers' constants. Gated on
 `capabilities.ws`; cross-process only, and only for a backend that mounts the
-flood action on its WS endpoint. fuz_app's own wiring is
-`src/test/cross_backend/ws_outbound_overflow.cross.test.ts`.
+flood action on its WS endpoint.
 
 ### `cross_backend/ws_connection_cap.ts` — `describe_ws_connection_cap_cross_tests`
 
@@ -1326,8 +1753,7 @@ overridden; pass the consumer's value when it sets one, `null` (cap disabled)
 to skip. **Consumer-agnostic** like the WS round-trip suite (`heartbeat` only).
 A separate call rather than more cases on that suite because each case opens
 more than a cap's worth of real sockets. Gated on `capabilities.ws`;
-cross-process only. fuz_app's own wiring is
-`src/test/cross_backend/ws_connection_cap.cross.test.ts`.
+cross-process only.
 
 ### `cross_backend/session_cap.ts` — `describe_session_cap_cross_tests`
 
@@ -1335,12 +1761,13 @@ Parity for the per-account session cap over real HTTP: logging in past
 `max_sessions` (default `DEFAULT_MAX_SESSIONS`) never refuses a login and
 evicts the oldest session.
 `describe_session_cap_cross_tests({setup_test, max_sessions?, login_path?,
-status_path?, ws?})` — pass `ws` (`{base_url, ws_path, origin?}`) to also
+status_path?, ws?, ws_account_roles?})` — pass `ws` (`{base_url, ws_path, origin?}`) to also
 assert that the evicted session's socket is closed with
 `WS_CLOSE_SESSION_REVOKED` once the evicting login commits; omitted, that case
-is skipped, so a caller passes it only for a backend with `capabilities.ws`.
-Cross-process only. fuz_app's own wiring is
-`src/test/cross_backend/session_cap.cross.test.ts`.
+is skipped, so a caller passes it only for a backend with `capabilities.ws`;
+`ws_account_roles` gives that case's account roles, for a backend whose WS
+upgrade requires one.
+Cross-process only.
 
 ### `cross_backend/sse_round_trip.ts` — `describe_cross_process_sse_tests`
 
@@ -1370,8 +1797,7 @@ admin each drop its stream — the rows `create_account_revocations`
 session closes the oldest and leaves the rest open. The data-frame + close
 cases gate on `rpc_path` (they drive the standard account/admin actions); all
 cases gate on `capabilities.sse`. Cross-process only — wire from a
-`*.cross.test.ts`. fuz_app's own wiring is
-`src/test/cross_backend/sse.cross.test.ts`, which runs on every backend — the
+`*.cross.test.ts`. It runs on every fuz_app backend — the
 TS spines wire `audit_log_sse` and the Rust `spine_stub` serves the same
 stream.
 
@@ -1389,7 +1815,7 @@ covered on WS and SSE at once. The drivers stand alone too: `cross_post_as`
 `cross_admin_token_revoke_all`, and `cross_account_purge` (over the daemon
 token, no `Origin`).
 
-### `cross_backend/cell_crud.ts` + `cell_relations.ts` + `cell_gated_create.ts` — cell parity suites
+### `cross_backend/cell_crud.ts` + `cell_relations.ts` + `cell_gated_create.ts` + `cell_moderate.ts` — cell parity suites
 
 The cell-layer parity coverage is split across two sibling suites. Cells
 can't ride the generic `describe_rpc_round_trip_tests` (stateful verbs need a
@@ -1400,7 +1826,19 @@ cell validators (`describe_standard_cross_process_tests`' generic round-trip
 never sees them). Both parse every success response against the verb's Zod
 **output** schema, so a TS↔Rust envelope drift fails the suite — not just a
 payload-field drift. Call-site primitives (`cross_rpc_call` / `error_reason` /
-`expect_output`) live in `cross_backend/cell_cross_helpers.ts`; the shared
+`expect_output`) live in `cross_backend/cross_rpc.ts`, shared by every
+stateful cross suite (a reply that is no JSON object throws naming the method,
+the HTTP status and the body's head), and every
+suite that reads audit rows goes through `cross_backend/audit_cross_helpers.ts`
+— `list_audit_events(fixture, params, rpc_path?)` drains
+(`cross_drain_effects`, the `_testing_drain_effects` barrier) before it lists and
+parses, so no reader skips the barrier, and parses every row's metadata
+(`assert_audit_event_metadata`, closed to undeclared keys when the fixture's
+setup asked), so every reader holds the rows it reads to their event's
+schema. A suite pinning a row's values uses `assert_audit_metadata_fields(fixture,
+metadata, expected, absent?)` — each field compared on its own so a consumer's
+added key passes, the `absent` keys refused, and the whole object compared only
+when the fixture closed the world; the shared
 options shape is `RpcPathCapabilityGatedCrossSuiteOptions` from
 `cross_backend/setup.ts`. `cross_backend/wire_shapes.ts` carries
 `assert_iso8601_seconds` / `assert_iso8601_seconds_nullable` — the byte-level
@@ -1413,7 +1851,7 @@ an audit row, an admin account listing, and an offer's `created_at` /
 imperative cross suite aliases: `CrossSuiteOptions` (`setup_test` alone),
 `CapabilityGatedCrossSuiteOptions` (+ `capabilities` — `ready`),
 `RpcPathCrossSuiteOptions` (+ `rpc_path?` — origin, body-size (which adds `base_url`), actor
-lookup/search, app settings, testing backdoor), and the intersection
+lookup, app settings, testing backdoor), and the intersection
 `RpcPathCapabilityGatedCrossSuiteOptions` (every `cell_*` suite, query-shape,
 token-scope surface, fact-serving, account lifecycle). A suite takes the
 capability-carrying variant only when it actually gates cases on a flag, so
@@ -1426,20 +1864,28 @@ the option type states whether the bundle is read.
   `path` write by non-admin → 403 on create + update; `cell_get` with no
   id/path → `invalid_params`; null-auth `cell_list` `created_by` →
   `invalid_params`; a `kind` at `CELL_KIND_LENGTH_MAX` stored whole, one
-  UTF-16 code unit past it → `invalid_params` on create and as a list filter).
+  UTF-16 code unit past it → `invalid_params` on create and as a list filter;
+  `cell_list` pages honoring `limit` + `offset`, a page holding visible rows
+  only and filling to `limit` past a newer run of rows the caller can't see —
+  two owners' private cells, read by a non-owner and by anon — and an admin's
+  pages tiling every row).
 - **`describe_cell_relations_cross_tests`** (gates on
   `capabilities.cell_relations`) — the verbs beyond CRUD: grant lifecycle
   (actor-shaped editor grant enables edit, manage-tier `cell_grant_list`,
   revoke), the now-reachable `cell_visibility_manage_only` 403 (editor-grant
   holder can't flip visibility), field set / forward+reverse list / idempotent
   delete, item insert / ordered forward+reverse list / move / idempotent
-  delete, clone shallow (shares edges) vs deep (clones children), and
+  delete, an insert or move onto a taken position → `cell_item_position_taken`
+  with the rows unchanged, clone shallow (shares edges) vs deep (clones children), and
   manage-tier `cell_audit_list` (owner reads the timeline; a viewer-grant
   holder who can `cell_get` still gets the IDOR 404). Only **actor-shaped**
   grants are exercised — role-shaped principals need a closed role registry the
   Rust spine deliberately lacks.
-- **`describe_cell_gated_create_cross_tests`** + **`describe_cell_moderate_cross_tests`**
-  (gate on `capabilities.cell_gated_create`, **cross-only**) — the parent-aware
+- **`describe_cell_gated_create_cross_tests`** (`cell_gated_create.ts`) +
+  **`describe_cell_moderate_cross_tests`** (`cell_moderate.ts`)
+  (gate on `capabilities.cell_gated_create`, **cross-only**; both build their
+  spaces on `TEST_SPACE_POLICY`, exported beside the authorizer in
+  `test_cell_gated_create_authorize.ts`) — the parent-aware
   cell-creation authorizer (`CellCreateAuthorize`, **directory model**) +
   the `cell_moderate` verb parity proofs. Both spines mount the same
   `test_cell_gated_create_authorize` policy (its admin bypass and `min_role`
@@ -1453,7 +1899,9 @@ moderation_required}`, with `moderation` set per the verdict (`pending`+private
   **visible** one **403**s; plain parentless creates stay open. The moderate
   suite then proves the `pending → approved | rejected` transition: an admin
   (root manager) approves → public, the **author** self-approve → 403
-  (anti-self-approval), a non-viewer → 404, reject → stays private. It also
+  (anti-self-approval), a non-viewer → 404, reject → stays private, and a cell
+  with no governing root → 400 `cell_not_a_contribution` for any viewer, the
+  404 mask first for a non-viewer. It also
   pins the moderation read gate (a pending or rejected post reaches no
   non-steward reader past its author and admins on `cell_get`, `cell_list`,
   `cell_item_list`, and fact serving, even flipped public or granted while
@@ -1469,8 +1917,7 @@ moderation_required}`, with `moderation` set per the verdict (`pending`+private
 
 `cell_crud` / `cell_relations` gate `true` on TS + Rust (cells run on both, no
 `.skip`); `cell_gated_create` is cross-only (the policy is a spine-binary
-fixture). Cross-process wiring is `src/test/cross_backend/cell.cross.test.ts`
-(all the cell suites); the in-process legs (plain `gro test`) for crud/relations
+fixture). The in-process legs (plain `gro test`) for crud/relations
 are `src/test/auth/cell_crud_parity.db.test.ts`
 
 - `cell_relations_parity.db.test.ts`, sharing the full-surface
@@ -1486,11 +1933,59 @@ are `src/test/auth/cell_crud_parity.db.test.ts`
   `rust_spine_stub_backend_config()` as a convenience preset for the non-domain
   third spine consumer, but otherwise backend-specific paths and env are a
   consumer concern.
+- `testing/cross_backend/default_backend_configs.ts` —
+  `make_default_ts_backend_config` / `make_default_rust_backend_config`, the
+  family builders a consumer config composes: the env baseline (`HOST` bound
+  to `DEFAULT_TEST_BACKEND_HOST`, `127.0.0.1`; the port under
+  `port_env_var`; cookie keys; allowed origins; the bootstrap token path; the
+  Rust startup self-wipe), the default paths, and the required `capabilities`.
+  `daemon_token_dir_env` names the env var the binary reads its daemon-token
+  directory from, set to the `{dir}` whose `{dir}/run/daemon_token` is the
+  bootstrap's `daemon_token_path` (`to_daemon_token_dir`, which throws for a
+  path in another layout).
+- `testing/cross_backend/create_cross_backend_global_setup.ts` —
+  `create_cross_backend_global_setup({configs, derive_name?, provide_key?,
+  ensure_databases?, before_spawn?})`, the single-backend `globalSetup` maker:
+  the backend name derived from the vitest project name selects a config,
+  which is spawned, bootstrapped and provided. `before_spawn` (by backend
+  name; a key naming no config, an inherited one included, throws at
+  construction) runs first for the selected backend — `prepare_cargo_binary`
+  for a Rust one — then its config factory, then `ensure_databases: true`
+  creates the database the config's `postgres:` `env.DATABASE_URL` names
+  (`ensure_database_for_url`), then the spawn. A second argument
+  (`CrossBackendGlobalSetupDeps`) swaps the database creator and the spawn,
+  for testing the setup itself.
+- `testing/cross_backend/cargo_binary.ts` — `prepare_cargo_binary({workspace_dir,
+  package, bin?, profile?})` builds a Cargo binary (`cargo build -p --bin
+  --profile`, output inherited, a failed build throws) unless
+  `NO_REBUILD_ENV` (`FUZ_TESTING_NO_REBUILD`, `is_no_rebuild_requested`) asks
+  to skip it, and returns its path; `resolve_cargo_binary_path(options)` is the
+  path alone, for a config's `start_command` — under the `target_directory`
+  `cargo metadata` reports (memoized per process per workspace), in the
+  profile's directory (`to_cargo_profile_dir`: `dev` → `debug`;
+  `to_cargo_binary_path` reads it from the metadata JSON). Run as
+  `create_cross_backend_global_setup`'s `before_spawn` hook, the build happens
+  before the spawn's startup window, with its output shown. fuz_app's own stub
+  rebuild (`rebuild_rust_spine_stub`) is built on it.
+- `testing/cross_backend/postgres_database.ts` — `ensure_database(database,
+  server_url?, deps?)` (idempotent `createdb` on the server the URL names, its
+  password passed in the environment; `createdb`'s already-exists refusal is
+  the quiet success case, `is_createdb_already_exists`, and any other failure
+  is reported through `deps.warn` — `console.warn` by default — with
+  `createdb`'s stderr, never thrown), `ensure_database_for_url(url, deps?)` (the
+  database a `postgres:` URL names; anything else left alone),
+  `with_database_name`, `to_maintenance_database_url`, `redact_database_url`
+  (a URL fit to print), `is_postgres_url`. The harness creates a database only
+  when a setup asks, so a test role needs no `CREATEDB` grant otherwise.
 - `testing/cross_backend/spawn_backend.ts` — `spawn_backend(config) => BackendHandle`.
-  Writes the bootstrap token, spawns `detached: true` in its own process
-  group (so SIGTERM to the negative pid tears down descendants), polls
-  health, reads the deterministic daemon token from the binary-written
-  file. Registers exit-time + signal cleanup so vitest worker death or
+  Refuses a port that already accepts connections, writes the bootstrap
+  token, deletes a stale daemon-token file, spawns `detached: true` in its
+  own process group (so SIGTERM to the negative pid tears down descendants),
+  polls health (each probe request timed out), reads the deterministic daemon
+  token from the binary-written file. Keeps a bounded stderr tail
+  (`create_output_tail`) for an early exit's error — with its exit code or
+  signal — and for the log line an unexpected exit after startup writes.
+  Registers exit-time + signal cleanup so vitest worker death or
   Ctrl+C kills children before they strand ports.
 - `testing/transports/fetch_transport.ts` — cookie-threading HTTP transport
   satisfying `RpcTestTransport`. Carries a name-keyed cookie jar that
@@ -1530,6 +2025,18 @@ are `src/test/auth/cell_crud_parity.db.test.ts`
   opens and round-trips `heartbeat` (response id `WS_ADMISSION_PROBE_ID`) so the
   connection is admitted when it resolves; suites that wait for a push, or need
   connections registered in a known order, open through it.
+- `testing/cross_backend/ws_endpoint.ts` — `WsEndpointTarget`
+  (`{base_url, ws_path, origin?}`), the endpoint shape the socket-driving
+  cross suites take (flat, or as an optional `ws` on
+  `describe_session_cap_cross_tests`, `describe_testing_backdoor_cross_tests`
+  and the conformance table; `describe_transport_composition_cross_tests`
+  keeps its own nullable `base_url` and defaulted `ws_path`), and
+  `open_session_ws(target, account, {admitted, on_request?, headers?,
+  default_timeout_ms?})`, which opens a socket on an account's session cookie
+  (`to_session_cookie`, asserted present) with `target.origin` or `base_url`
+  as the `Origin` — through `create_admitted_ws_transport` when `admitted`,
+  `create_ws_transport` otherwise. The cookie is the account's static one, so
+  a session rotated through `fixture.transport` upgrades stale.
 - `testing/transports/ws_raw_client.ts` — `connect_raw_ws({port, hostname?, path, headers?, pipelined?})`
   → `RawWsClient` (`{frames, send_text, wait_for, destroy}`), a WebSocket client
   over a raw `node:net` socket for the two things a client library can't do:
@@ -1551,8 +2058,12 @@ are `src/test/auth/cell_crud_parity.db.test.ts`
   `raw_http_parse_response` (the first response, `null` until its head and
   framed body are whole), `raw_http_count_responses` (unanchored status-line
   count, so a response concatenated after a body is seen),
-  `raw_http_first_status`. Shared by the body-size, body-size smuggling, and
-  credential-header suites.
+  `raw_http_first_status`, `raw_http_header_lines` (headers as CRLF lines),
+  `raw_http_parse_json` (a body's JSON, `undefined` when it isn't), and
+  `RAW_HTTP_READ_TIMEOUT_MS`, the suites' default read window. Shared by the
+  body-size, body-size smuggling, credential-header, origin-scope and
+  transport-composition suites, which take the 1 MiB cap they probe from
+  `SPINE_BODY_LIMIT_DEFAULT_BYTES` (`spine_surface_constants.ts`).
 - `testing/transports/sse_frame_reader.ts` — `create_sse_frame_reader(reader, default_timeout_ms?)`,
   the transport-agnostic SSE framing core over a
   `ReadableStreamDefaultReader<Uint8Array>`: `\n\n` framing, per-read timeout,
@@ -1690,10 +2201,52 @@ refs); and a hidden cell's update, a create under a hidden parent, and a clone
 of a hidden source answer `404` whatever `data` names. Facts are put through
 `cross_put_fact` (exported by `fact_serving.ts`), whose `holder` maps onto
 `_testing_put_fact`'s optional `holder` key. Gated on
-`capabilities.fact_serving`; cross-process only. fuz_app's own wiring is
-`src/test/cross_backend/cell_ref_admission.cross.test.ts`; the in-process
+`capabilities.fact_serving`; cross-process only. The in-process
 cases are `src/test/auth/cell_ref_admission{,.fact_less}.db.test.ts`.
 
+### Malformed-envelope and invalid-params parity — `cross_backend/rpc_adversarial.ts`
+
+`describe_rpc_adversarial_cross_tests({setup_test, surface_source, rpc_path?,
+live_rpc_endpoints?, skip_methods?})` — the envelope and params groups of
+`describe_rpc_attack_surface_tests`, sent over `fixture.transport` to a
+spawned backend. The in-process groups run on stub apps, while the Rust spine
+parses envelopes and params by hand and the action-manifest parity gate
+compares no param schemas, so this is what holds the spines to one answer.
+
+- **envelopes** — every `create_rpc_envelope_cases` case, one test each, on a
+  fresh fixture; status, code, echoed `id`, and `data.reason` per case, and a
+  guard test that the endpoint has both a read and an authenticated mutation to
+  carry them.
+- **params** — one test per declared method, sending every
+  `generate_rpc_params_test_cases` case and failing with the list of cases not
+  answered 400 `invalid_params` with no `data.reason`. `xfail_params`
+  (`RpcParamsXfail` — `{method, labels, tracking_id, reason}`) moves the named
+  cases of a method into one `xfail_until` test each, for a known divergence on
+  one backend; the method's other cases keep their test, and an entry naming no
+  generated case fails. Pass it only for the backend that diverges — fuz_app
+  keys it on `RUST_SPINE_STUB_DEFAULT_NAME`.
+
+The authorized principal is the keeper on the first channel the method's auth
+admits — its session, else its daemon token or API token over a no-`Origin`
+transport — resolved through `resolve_conformance_principal`.
+**Preconditions:** the keeper holds every role a declared method gates on
+(`default_cross_process_setup` seeds `keeper` and `admin`; `extra_keeper_roles`
+for others) and has a single actor. No generated body carries a valid `acting`,
+and a malformed one reads as omitted ahead of validation on both spines, so a
+single-actor keeper resolves its actor and validation refuses; a keeper with a
+second actor answers `actor_required` first, so such a suite lists the
+actor-required methods in `skip_methods`.
+
+**Off the declared surface.** `live_rpc_endpoints` (resolved) adds the methods
+the endpoint at `rpc_path` live-mounts beyond the declared surface — cell
+verbs, opt-in resolvers, `_testing_*` backdoors — to both groups: their
+envelope cases in a group of their own, and a params test per method,
+`_testing_*` included (a daemon-only backdoor goes with the keeper's daemon
+token). fuz_app's spine self-test passes `create_spine_live_rpc_endpoints()`.
+Skips `_testing_*` on the declared surface and `PROTOCOL_ACTION_METHODS`, which
+`generate_rpc_auth_conformance_cases` skips too.
+Ungated; cross-process only.
+
 ### Token-scope surface parity — `cross_backend/token_scope_surface.ts`
 
 `describe_token_scope_surface_cross_tests({setup_test, capabilities, rpc_path?,
@@ -1708,7 +2261,7 @@ the spec-derived suites can't see it (REST routes, off the declared RPC surface)
 Mints a narrowed bearer through the production `account_token_create` path and
 fires it at the two surfaces whose denial **body** is observable over plain
 HTTP — the audit SSE stream (`capabilities.sse`) and the admin-only bare-hash
-fact read (`capabilities.fact_serving`) — asserting the exact flat
+fact read (`capabilities.fact_serving_admin_hash`) — asserting the exact flat
 `{error: 'token_scope_required', required_scope: 'surface:<name>'}` both spines
 contract on (`token_scope_denied_body` ↔
 `fuz_auth::token_scope_surface_denied_response`).
@@ -1733,20 +2286,21 @@ _does_ name, and a full bearer must get past the scope gate on the same route.
 The WS upgrade is deliberately omitted — `create_ws_transport` threads cookies,
 not bearer headers, and a refused upgrade's body isn't readable, so it can't
 serve a body-parity gate (its per-spine coverage stays in the two surface
-censuses). Cross-process only; fuz_app's own wiring is
-`src/test/cross_backend/token_scope_surface.cross.test.ts`.
+censuses). Cross-process only.
 
 ### Front-door contract — `cross_backend/transport_composition.ts`
 
 `describe_transport_composition_cross_tests({setup_test, capabilities, base_url,
-rpc_path?, origin?, rest_path?, password_path?, ws_path?, sse_path?})` — the per-transport
+rpc_path?, origin?, rest_path?, password_path?, ws_path?, sse_path?,
+multi_actor?, rpc_max_body_bytes?})` — the per-transport
 composition table: what each transport answers before per-action dispatch,
 when one request trips several refusals. Rows are REST `POST` (session-only
 `/api/account/logout`), RPC `POST`, RPC `GET`, the WS upgrade (gated on
 `capabilities.ws`) and the audit stream (`capabilities.sse`); columns are a
 foreign `Origin` with the keeper's session (→ 403 `forbidden_origin`), an
 over-cap declared length with a foreign `Origin` and no credential (→ 413
-`payload_too_large`, body-carrying rows only), no credential (→ 401
+`payload_too_large`, body-carrying rows only; one byte past the spine default,
+or past `rpc_max_body_bytes` on the RPC row), no credential (→ 401
 `authentication_required`), and a narrowed bearer with no `Origin` (→ 403
 `token_scope_required` naming `rpc:<method>` on RPC and `surface:ws_upgrade` on
 the upgrade; 403 `credential_type_required` on the session-only REST route and
@@ -1756,12 +2310,17 @@ envelope's `error.data`. A WS refusal's body is required where the backend
 declares `capabilities.ws_refusal_body`; where it doesn't (Node's
 `@hono/node-ws` drops the body), an empty body passes on its status and a sent
 one is still asserted. The table
-is the exported `transport_composition_cases` data. Given `base_url`, every
+is the exported `transport_composition_cases` data. `multi_actor:
+{setup_test, xfail?}` adds `transport_composition_multi_actor_cases`, run on
+a fixture whose keeper has `extra_actors`: the keeper's session upgrading with
+no `?acting=` → 400 `actor_required` (flat body), the TS upgrade's actor
+resolution. The Rust spine's upgrade resolves no actor and admits the socket,
+so fuz_app passes `xfail` (tracking id `rust-ws-upgrade-acting-fail-open`) for
+the Rust stub only. Given `base_url`, every
 probe is written to the socket (`raw_http_exchange`) and an over-cap request
 sends its head alone; with `base_url: null` the probes go through the
 fixture's transport and the WS rows skip. Not in the standard bundle. fuz_app's
-own wiring is `src/test/cross_backend/transport_composition.cross.test.ts` and
-the in-process `src/test/auth/transport_composition_parity.db.test.ts`.
+in-process leg is `src/test/auth/transport_composition_parity.db.test.ts`.
 
 `cross_backend/narrowed_api_token.ts` — `mint_narrowed_api_token({app,
 rpc_path, session_headers, methods, name?})` mints a method-scoped api token
@@ -1773,7 +2332,7 @@ principal.
 ### Credential deadline parity — `cross_backend/credential_deadline.ts`
 
 `describe_credential_deadline_cross_tests({setup_test, capabilities, base_url,
-ws_path, sse_path?, rpc_path?})` — a connection closes when the credential it
+ws_path, sse_path?, rpc_path?, ws_account_roles?})` — a connection closes when the credential it
 opened on expires: each case pulls a fresh account's credential expiries in to
 two seconds with `_testing_shorten_credential_expiry` before the open, then
 checks the connection still dispatches short of the deadline and closes at it.
@@ -1783,17 +2342,24 @@ stream on a session (`capabilities.sse`) ends; and a second seam call asking
 for a later expiry moves nothing (the seam only shortens). API token × audit
 stream is not reachable over the wire — the stock stream is session-only — so
 the Rust spine pins it on a widened gate and the TS twin shares one deadline
-wait across both transports. Cross-process only; fuz_app's own wiring is
-`src/test/cross_backend/credential_deadline.cross.test.ts`.
+wait across both transports. The cases run concurrently (`describe.concurrent`)
+under one `setup_test()` for the suite, each on its own account, so a leg waits
+out one deadline rather than one per case. `ws_account_roles` gives the
+socket cases' accounts roles, for a backend whose WS upgrade requires one.
+Cross-process only.
 
 ### Origin check scope parity — `cross_backend/origin_scope.ts`
 
-`describe_origin_scope_cross_tests({setup_test, capabilities, probe_path?})` —
-the origin check covers paths outside `/api`: on `GET /ready` (`probe_path`), a
-foreign `Origin` → 403 `forbidden_origin`, an absent or allowed one → 200. Gated
-on `capabilities.ready`. Runs both legs (the in-process
+`describe_origin_scope_cross_tests({setup_test, capabilities, probe_path?,
+base_url?, unrouted_status?})` — the origin check covers paths outside `/api`:
+on `GET /ready` (`probe_path`), a foreign `Origin` → 403 `forbidden_origin`, an
+absent or allowed one → 200, gated on `capabilities.ready`. On an unrouted
+path, ungated: a foreign `Origin` → 403, an absent one passes to the fallback
+(`unrouted_status`, default 404 — a backend whose fallback serves an SPA shell
+passes 200; the in-process leg runs that shape too), and an over-cap `POST`
+with a foreign `Origin` → 413. Runs both legs (the in-process
 `cross_backend/origin_scope_parity.db.test.ts` + the cross-process
-`origin_scope.cross.test.ts`).
+one call).
 
 ### Origin verification parity — `cross_backend/origin.ts`
 
@@ -1803,7 +2369,7 @@ imperative Origin-verification suite: absent `Origin` → request passes
 table's. Imperative (not a conformance-table row) because absent-Origin needs
 `fresh_transport({origin: null})`. Runs both legs (the
 in-process `auth/origin_parity.db.test.ts` + the cross-process
-`origin.cross.test.ts`). The promotion surfaced a twin-impl divergence — the
+one call). The promotion surfaced a twin-impl divergence — the
 Rust spine returned a plain-text body — now converged to the canonical TS
 `{error: "forbidden_origin"}` via `fuz_http::forbidden_origin_response()`.
 
@@ -1823,7 +2389,6 @@ keeper's daemon-token channel; the TS unit leg runs the same rows through
 `run_testing_origin_check` (`src/test/http/origin.conformance.test.ts`), so the
 Rust spine is held to the table without reading the file. Ungated; edit the
 table by hand — it is the statement of the grammar, not generated output.
-fuz_app's own wiring is `src/test/cross_backend/origin_conformance.cross.test.ts`.
 
 ### CORS simple-request parity — `cross_backend/simple_request.ts`
 
@@ -1839,7 +2404,7 @@ and login, form-encoded login, a forged `text/plain` logout with a session
 `application/json` with a charset is dispatched. The TS spine checks per route
 (`apply_route_specs`), the Rust spine in each JSON handler. Runs both legs:
 the in-process `auth/simple_request_parity.db.test.ts` and the cross-process
-`simple_request.cross.test.ts`.
+one call.
 
 ### Query-string shape parity — `cross_backend/query_shape.ts`
 
@@ -1850,7 +2415,7 @@ suite over the three spine surfaces that read a query:
 unknown keys ignored, anonymous junk query → 401 never a query 400), the
 JSON-RPC GET endpoint (`method` / `id` / `params` first-wins — a last-wins
 reader dispatches a different method per backend on the same request), and
-`GET /api/facts/:hash` (gated on `capabilities.fact_serving`; strict schema —
+`GET /api/facts/:hash` (gated on `capabilities.fact_serving_admin_hash`; strict schema —
 unknown key / malformed `acting` → 400 `invalid_query_params` **before** the
 401 guard, duplicated `acting` first-wins). Imperative because duplicated
 query keys can't be expressed through the structured RPC helpers. Pinned
@@ -1859,8 +2424,7 @@ after the Rust spine's derived-serde `Query` extractors were converged onto
 "duplicate field" 400 is an anonymously observable backend fingerprint).
 Cross-process only — the per-surface in-process TS pins live beside each
 module's own tests (`account_status.test.ts`, `action_rpc.test.ts`,
-`serve_fact_route.db.test.ts`); fuz_app's own wiring is
-`cross_backend/query_shape.cross.test.ts`.
+`serve_fact_route.db.test.ts`);
 
 ### Grant-verb role grammar parity — `cross_backend/role_grant_role_grammar.ts`
 
@@ -1875,8 +2439,7 @@ vacuous, and the same refusal for a role exactly at the length cap pins that
 boundary. Exists because the action-manifest parity gate captures no param
 schemas while the Rust spine parses params by hand, and the grant verbs write
 the role they refuse into their failure rows. Ungated; cross-process only (it
-reads the audit log behind `_testing_drain_effects`). fuz_app's own wiring is
-`src/test/cross_backend/role_grant_role_grammar.cross.test.ts`.
+reads the audit log behind `_testing_drain_effects`).
 
 ### API-token lifetime parity — `cross_backend/token_lifetime.ts`
 
@@ -1891,7 +2454,7 @@ schemas while the Rust spine hand-parses params — a spine that silently
 dropped the field would answer the same mint with a 200 and an eternal
 token; only the stored-state read-back catches it. Ungated (mint + list are
 on every spine's standard surface). Runs both legs
-(`token_lifetime_parity.db.test.ts` + `token_lifetime.cross.test.ts`).
+(`token_lifetime_parity.db.test.ts` + the cross-process one call).
 
 ### Readiness probe parity — `cross_backend/ready.ts`
 
@@ -1906,7 +2469,7 @@ success-path gate. Gated on `capabilities.ready`. Imperative (not a
 JSON-RPC envelope, and the probe needs `fresh_transport({origin: null})` —
 the same reasons the sibling `cross_backend/origin.ts` suite is imperative.
 Runs both legs (`cross_backend/ready_parity.db.test.ts` +
-`cross_backend/ready.cross.test.ts`).
+the cross-process one call).
 
 Both backends read the **same** committed
 `testing/cross_backend/expected_schema.json` (column-presence is engine-portable,
@@ -1931,8 +2494,7 @@ same MAC under `atob`), an unpadded signature, and correctly signed
 with `authentication_required`. Controls: re-signing the keeper cookie's
 payload reproduces it byte for byte and it authenticates, and a leading-zero
 `0N` authenticates (the `u64` bound is on the value, not the digit count).
-Ungated; cross-process only. fuz_app's own wiring is
-`src/test/cross_backend/session_cookie_codec.cross.test.ts`.
+Ungated; cross-process only.
 
 ### Testing-backdoor credential gate — `cross_backend/testing_backdoor.ts`
 
@@ -1954,11 +2516,14 @@ runs. Cited property: `docs/security.md`
 §Test Backdoor Actions. Cross-process only (the `_testing_*` actions are
 mounted on the spawned binary, not the in-process app — like the ws/sse
 suites); ungated, since every cross backend that uses
-`default_cross_process_setup` mounts them. fuz_app's own wiring is
-`src/test/cross_backend/testing_backdoor.cross.test.ts`. The complement is the
+`default_cross_process_setup` mounts them. The complement is the
 in-process spec-level gate test (`src/test/testing/testing_actions_auth.test.ts`,
 asserting each spec declares `credential_types: ['daemon_token']`) + the
-`assert_no_testing_methods` surface invariant.
+`assert_no_testing_methods` surface invariant. fuz_app's conformance table
+also covers the same gates, through the auth rows it generates over the live
+mount (`live_rpc_endpoints`), which the differential compares across spines;
+this suite stays for consumers whose backends mount the `_testing_*` actions
+without a conformance table over their live mount.
 
 ### Identity-primitive parity — `cross_backend/identity_parity.ts`
 
@@ -2015,7 +2580,7 @@ USERNAME_LENGTH_MAX]` = `[3, 39]` boundary edges (just-outside → 400,
 
 Ungated (login + signup are on every spine). Runs both legs via the shared
 `{setup_test}` protocol: in-process (`identity_parity.db.test.ts`, plain
-`gro test`) and cross-process (`identity_parity.cross.test.ts`).
+`gro test`) and cross-process (the one call).
 The accepted-case 403s rely on `create_spine_route_specs` zeroing
 `signup_fail_floor_ms` (mirroring `login_fail_floor_ms: 0`) so they don't each
 pay the 250ms denial floor.
@@ -2146,6 +2711,15 @@ need a real recipient): admin **assigns** `participant` to a fresh account
 `participant` → recipient **accepts** → a role_grant lands. The `role_holder`
 principal is seeded via `extra_accounts: [{username, roles: ['participant']}]`
 (bootstrap-cradle direct grant) and named through `principals.role_holder`.
+The replay cases count audit rows behind `_testing_drain_effects`, so the
+backend must mount it — every spine binary does; an in-process leg mounts
+`create_testing_drain_effects_action` over an emitter built with
+`track_inflight: true` (`conformance_participation.db.test.ts`).
+`role` (default `SPINE_PARTICIPANT_ROLE`) names the role conferred, which must
+be admin-grantable in the backend's registry; `scope_kind` (default `'space'`,
+or `null` for a builtin role) is the scope the scoped-assign case uses, and
+`null` skips it. A backend with only the builtin roles runs the suite with
+`ROLE_ADMIN` — the scoped case skips, as a builtin is global-only.
 
 Both legs run in-process (`conformance_participation.db.test.ts`, plain
 `gro test`) and cross-process (`conformance_participation.cross.test.ts`, TS
@@ -2154,6 +2728,38 @@ the `cross_backend_parity` action-manifest gate green (it was Rust-only before).
 Cited property: `docs/identity.md` + the role-gated-participation design
 (admin-only conferral, immediate assign).
 
+### Offer decline + retract refusals — `cross_backend/role_grant_offer_lifecycle.ts`
+
+`describe_role_grant_offer_lifecycle_cross_tests({setup_test, rpc_path?, role?})` —
+the error paths of the two verbs that end a pending offer without a grant,
+which the WS notification suite drives only on the happy path. Canonical
+answers, from the handlers and the queries behind them
+(`auth/role_grant_offer_actions.ts`, `auth/role_grant_offer_queries.ts`):
+
+- **not a party → 404** `not_found` with reason `role_grant_offer_not_found`.
+  Decline is scoped to the recipient account and retract to the grantor actor,
+  so a stranger, the grantor declining, or the recipient retracting hears what
+  a missing offer answers — the case compares the two refusals whole — and the
+  offer stays pending (`docs/security.md` §"404-over-403 is the general mask").
+  The scope check runs before the terminal check, so a stranger hears 404 on
+  a decided offer too.
+- **decided → 400** `invalid_request` with reason `role_grant_offer_terminal`:
+  a decline or retract after an accept, a second decline, a second retract,
+  and either after the other.
+- **audit**: a decline writes one `role_grant_offer_decline` row
+  (`account_id` / `actor_id` the recipient, `target_*` the grantor, metadata
+  `{offer_id, role, scope_id}` plus `reason` only when one was given), a
+  retract one `role_grant_offer_retract` row (the grantor, targeting the
+  recipient, no target actor on an account-grain offer); refusals write none.
+  Read through `list_audit_events`.
+
+The single-request rows — decline and retract of an id naming no offer → 404
+— are in the conformance security slate, so the differential sends them to
+both spines. The keeper is the grantor and offers `role` — an admin-grantable
+role, `SPINE_PARTICIPANT_ROLE` by default; `ROLE_ADMIN` serves a backend with
+only the builtin roles. Ungated. The
+in-process leg is on the drained setup of `conformance_participation.db.test.ts`.
+
 ### Building a TS test-server binary — `testing_server_core.ts` + adapters
 
 The reusable shape for standing up a **spawnable TS** cross-process test
@@ -2165,7 +2771,7 @@ re-roll the serve / daemon-info / WS-attach / drain boilerplate:
 - `testing/cross_backend/testing_server_deno.ts` — `create_deno_testing_adapter()` (`Deno.serve` + `@hono/deno`, an optional peer dep; `Deno` declared locally so it typechecks under the Node toolchain). Spawn the entry with `--sloppy-imports` (Deno doesn't do `.js`→`.ts`; Gro's loader does, so the Node path needs no flag).
 - `testing/cross_backend/testing_server_bun.ts` — `create_bun_testing_adapter()` (`Bun.serve` + `@hono/bun`'s module-level `getConnInfo`, `upgradeWebSocket`, and `websocket`; `Bun.serve` declared locally so it typechecks under the Node toolchain). Needs the optional `@hono/bun` peer dep (the counterpart to Node's `@hono/node-server` + `@hono/node-ws`; `Bun.serve` is built in), and Bun resolves `.js`→`.ts` natively (no flag, unlike Deno). Reuses `create_node_runtime` (Bun implements the `node:fs`/`node:process` surface). WS is module-level + stateless (like Deno) — the `websocket` handler is threaded into `serve`, where `Bun.serve` wants it, so no post-serve attach. It carries `maxPayloadLength` at twice `max_message_bytes` rather than Bun's 16 MiB default: past its cap Bun drops the socket without a close frame (1006), so the headroom leaves a message just over the limit to the per-message check (`WS_CLOSE_MESSAGE_TOO_BIG`, as on Node), while a grossly oversized one is refused before Bun buffers it whole.
 - `testing/cross_backend/default_spine_surface.ts` — the canonical no-domain spine surface (account/admin/audit/signup + bootstrap): `spine_session_options`, `spine_roles`, `create_spine_route_specs`, `spine_rpc_endpoints`, `create_spine_surface_spec`. This is the **declared** surface — the `create_standard_rpc_actions` bundle the spec-derived suites auto-enumerate. It passes `daemon_token: true` (both spine binaries mount the daemon-token layer) and leaves `GET /api/surface` at its default, off — the TS spine binary does too, and the Rust `testing_spine_stub` serves none. Shared by the spine_stub cross test, the TS cross tests, and the binary.
-- `testing/cross_backend/full_spine_mount.ts` — `build_full_spine_rpc_actions(deps, options)` — the **full** live RPC mount: the declared bundle **plus** the off-declared-surface families the binary live-mounts (`_testing_*` backdoors, the cell verb set, the opt-in `actor_lookup` / `actor_search` resolvers). `build_full_spine_mount(deps, options)` builds it once for both of the binary's endpoints, returning `FullSpineMount` (`{rpc_actions, ws_actions}`): the WS list is `protocol_actions` plus every RPC action not already among them, twinning the Rust `testing_spine_stub`, which serves one registry on RPC and WS (the one difference is `cancel` — a registered protocol action on TS, owned by the read loop on Rust). Single-sources the mount so the binary and the `spine_method_coverage` reconciliation test build the same list.
+- `testing/cross_backend/full_spine_mount.ts` — `build_full_spine_rpc_actions(deps, options)` — the **full** live RPC mount: the declared bundle **plus** the off-declared-surface families the binary live-mounts (`_testing_*` backdoors, the cell verb set, the opt-in `actor_lookup` / `actor_search` resolvers). `build_full_spine_mount(deps, options)` builds it once for both of the binary's endpoints, returning `FullSpineMount` (`{rpc_actions, ws_actions}`): the WS list is `protocol_actions` plus every RPC action not already among them, twinning the Rust `testing_spine_stub`, which serves one registry on RPC and WS (the one difference is `cancel` — a registered protocol action on TS, owned by the read loop on Rust). Single-sources the mount so the binary and the `spine_method_coverage` reconciliation test build the same list. `create_spine_live_rpc_endpoints()` wraps the list, built on stub deps, as one endpoint at `SPINE_RPC_PATH` — the `live_rpc_endpoints` value the conformance table, the differential and the auth-row generator resolve off-surface methods from (no handler built there runs).
 - `testing/cross_backend/ts_spine_backend_config.ts` — `ts_spine_node_backend_config()` / `ts_spine_deno_backend_config()` / `ts_spine_bun_backend_config()` presets (in-memory pglet, no external infra), the TS analog of `rust_spine_stub_backend_config()`.
 
 fuz_app's own binary wiring (`src/test/cross_backend/testing_spine_server{,_node,_deno,_bun}.ts`) is the worked example: ~one `build_app` over `create_app_backend` + `create_app_server` (`rate_limiters: 'disabled_for_testing'` plus whichever login / action limiters its env toggles built, `build_full_spine_mount`'s two lists on one `rpc_endpoints` entry and two `ws_endpoints` entries — `/api/ws` and the role-gated `SPINE_ROLE_GATED_WS_PATH` — sharing one `transport`, which is also the role-grant-offer `notification_sender`), reusing `default_spine_surface`. `src/test/cross_backend/testing_spine_server.db.test.ts` builds it with the Node adapter in-process and asserts its surface lists both WS endpoints (the gated one with its `required_roles`) and passes the surface invariants. The `_node`/`_deno`/`_bun` entries differ only in which adapter they wire — `build_spine_app` is runtime-agnostic. It leaves `create_app_server`'s `auth_cleanup` off, as the Rust `testing_spine_stub` leaves its twin unscheduled: a background pass would delete rows and write audit rows under a running suite. A consumer's cross-process test binary may schedule it when nothing its suites seed is already expired (the conformance table's `expired_session` principal seeds a backdated session row); an in-process harness leaves it off.