One role's privileges in a Postgres database

Renders the operations to SQL (names quoted, expressions as given, each exactly one SQL expression) and runs them on one of the branch's Postgres databases as the owner (Admin only) or, with `role`, as that role (the SQL editor's session: your member role, then `SET ROLE`), in one transaction with `lock_timeout` (`lock_timeout_ms`, default 5000) and `statement_timeout` (60 s; 15 s for a dry run). A dry run runs the same statements and always rolls back; it evaluates your expressions (defaults, checks, `USING`), so their non-transactional side effects (e.g. `nextval`) remain. A statement that may rewrite a table over `CHELABASE_TABLE_API_DRY_RUN_MAX_BYTES` (default 256 MiB), and every one after it, is only rendered in a dry run (`skipped`), and then `would_succeed` is null. A table the request names that doesn't exist (and no earlier operation creates) is 404 with its `op_index`. Drops end `RESTRICT` and a request with drops returns `dependents`: what `CASCADE` would also remove beyond the request's own drop targets and their parts, and their `hash`. When something depends on a drop and the request confirms no cascade, the dry run and the real run alike answer 409 `has_dependents` with `dependents`, and change nothing. To cascade, send that hash as `cascade.dependents_hash`: the run (dry or real) locks the drop targets' tables, reads the dependents again, and refuses with 409 `dependents_changed` when they differ or when Postgres reports dropping anything but them and the parts of the request's other drop targets (drops that reach each other, e.g. a parent table and its child, need the hash of no dependents); a drop whose target an earlier drop of the request already removed is `skipped` (`already_dropped`). A `CONCURRENTLY` index operation must be the request's only operation: it runs outside a transaction (`statement_timeout` 900 s; a dry run only checks it), can't cascade, and when its build fails after creating its index, that INVALID index is dropped (another index of the same name never is). Postgres errors keep their fields (`op_index`, `sqlstate`, `message`, `detail`, `hint`, `position`; `dry_run: true` on a dry run). Each request is logged with its operation count, never its SQL.