Disabled orgs are still granted permissions through the Check API

The disabled-org gate added in #1860 covers the management and resource RPCs (the authorization map), but the SpiceDB Check API is deliberately out of its scope:

• CheckResourcePermission
• BatchCheckPermission
• CheckFederatedResourcePermission

These are on the authorization skip list and answer purely from SpiceDB tuples. Because disabling an org leaves its tuples in place (by design, so re-enable restores access), these endpoints keep returning allowed = true for resources of a disabled org. External services that gate their own access on these checks will keep serving a disabled org's resources.

Two ways to close it

1. Handler/service guard (Postgres read): resolve each checked resource to its org and return false when the org is disabled. Simple, no migration, but adds 1–3 point reads per check on a hot path, and overloads "denied" to also mean "suspended".
2. SpiceDB marker relation (preferred): add a suspended relation on the org that every permission subtracts (- org->suspended); write the tuple on disable, remove it on enable. Reflects org state in every check — single, batch, and federated — with no extra Postgres reads, since it rides the existing permission traversal. Requires a schema migration, disable/enable flow changes, and a backfill for currently-disabled orgs. Care needed so platform/superuser permissions are not subtracted (admins must still manage and re-enable).

Recommendation: option 2.

Relates to #1585.

Start by tracing CheckResourcePermission, BatchCheckPermission, and CheckFederatedResourcePermission, then follow the existing disable and enable flows and authorization schema. Implement the recommended SpiceDB suspended relation, including schema migration, tuple updates, and a backfill for currently disabled organizations. Done means all three checks deny disabled-org resources while platform and superuser permissions still work.