Tenant isolation: fail-open on lookup error, and NULL-org rows visible to every tenant

[krlex]

Closes H3 and M6 from the 2026-08-19 Codex review. Both are ways a
tenant-scoped request could end up seeing rows outside its tenant.

H3 — a failed tenant lookup ran the request with no RLS scope

_resolve_tenant_org caught every exception from the organization query and
returned None. __call__ cannot tell that None apart from the legitimate one
— superuser, or a user with no tenant — so it proceeded without installing a
scope, and Postgres RLS reads an unset forail.current_tenant_id as every row.
A transient database error during the lookup turned a tenant's request into a
global one.

The outer try/except in __call__ looked like a guard but never fired: the
exception had already been swallowed a level down.

A failed lookup is not evidence that the user has no tenant — it is evidence
that we do not know, and the only safe answer to that is to refuse. Which is
already what a failed set_tenant_id does two lines below. The resolver now lets
the error out and the middleware fails closed with the same 500, gated on
tenancy and RLS being on so a single-tenant install cannot start answering
500 because of this gate.

M6 — RLS treated every NULL organization as globally shared

Both policy builders emitted OR organization_id IS NULL for every table, on the
reasoning that a NULL organization marks an AWX resource shared platform-wide.
That is true of a handful of inherited tables and of none of ours — 20 of the
22 covered tables have a nullable organization. One scan result, drift alert,
audit event or inventory saved without an organization was readable by every
tenant.

RLS_GLOBAL_NULL_ORG_TABLES now names the five where a NULL organization is a
real ownership or sharing mechanism: user-owned credentials and OAuth
applications, globally shared execution environments, and system job templates
and their runs. Everything else — including every Forail-authored table, where
our own code assigns the organization — is scoped strictly. The indirect policy
follows the parent table, since the parent carries the organization; the orphan
bypass stays, because a row with no parent has no organization to compare
against.

Behaviour change, stated in migration 0211: on a tenant-scoped request,
existing rows with no organization in a strictly-scoped table stop being
returned. They are not deleted, and superusers and unscoped requests still see
them. If a resource disappears for a tenant, assign its organization — do not add
its table to the global list.

Verified

• tests_standalone/test_tenant_isolation.py — new file, 10 tests; the
  middleware had none. Against the pre-fix code two fail for the right reason:
  the view runs anyway, and the resolver swallows the database error.
• tests_standalone/test_tenancy.py — 90 passed, including a closed-list
  assertion on the global tables so growing it cannot be quiet, and a check that
  every Forail table is strictly scoped.
• Full standalone matrix green, except test_dynamic_survey_standalone.py, which
  cannot be collected on develop at all — that is fixed in forail-backend#6 and
  is why CI still excludes it here.