testing/cross_backend/cell_gated_create.ts

Cross-backend parity suite for the parent-aware cell-creation authorizer (CellCreateAuthorize) — the directory model.

The authorizer adds no method, column, or wire shape, so the schema-snapshot and action-manifest parity gates are blind to a TS↔Rust authorizer divergence (the authorizer in the wrong phase, a different deny shape, the 404/403 split, the moderation outcome). This behavioral cross case is the only gate that catches one — proven *here in fuz_app*, against both reference spines.

Both spines mount the same directory-model policy (the TS spine binary via create_test_cell_gated_create_authorize, the Rust testing_spine_stub via TestCellGatedCreateAuthorize): admin bypasses; a non-admin creating a kind: 'space' root is denied (admin-only); a contribution under a space is gated by the space's data.policy[kind] = {min_role, moderation_required}, with the moderation outcome folded into the verdict; plain parentless creates stay open. The suite asserts all spines agree on:

• root-create admin-only — a non-admin space root → 403 cell_create_forbidden; admin → succeeds.
• contribution gated by the root's policy — under a public space, an unauthorized stranger → 403; a participant → succeeds.
• moderation per moderation_required — a participant's post (moderation_required: true) is born moderation: 'pending' + private; a react (moderation_required: false) is born moderation: 'approved' at the author's visibility.
• 404 on a hidden parent vs 403 on a visible one — a contribution under a private space the caller can't view → 404 cell_not_found (the parent is masked); under a public space → 403 (you see it, you can't contribute).

Gated on capabilities.cell_gated_create — true only on the reference spine binaries that mount the policy, so it skips for generic consumers and the in-process default app (the authorizer hook's in-process coverage is the standalone auth/cell_create_authorize.db.test.ts).

$lib-free by contract (relative specifiers only).