A stranger's account may write to your tables

An access policy has two sides. `using` governs reading and modifying existing rows, `with check` governs which values may be written. Securing only the first leaves a table that looks properly locked down yet can be filled by anyone who signs up.

The static counterpart is `RSC-SEC-067` (`with check (true)` in the source). This rule proves the same at runtime — and finds it even when the migrations are not in the repository at all. For Lovable apps that is the normal case, because the schema only lives in the dashboard.

The check writes as little as possible: it sends a create attempt with an EMPTY body and evaluates what stops it. If the access policy rejects it, all is well. If only the database schema stops it (a missing required column), the policy is permissive — and still nothing was written. Only if a row is actually created is it removed afterwards; if that fails, it is named in the report.