Direct `sql` operation bypasses the operations allowlist (gate 1)

### Summary

A direct `sql` operation is authorized only by the AST table/attribute check, never by the role's `operations` allowlist (gate 1) or `requires_su`. A role that omits `sql` from its `operations` can still run arbitrary SQL, bounded only by its table CRUD grants.

### Detail

In `chooseOperation` (`server/serverHelpers/serverUtilities.ts:264-266`), SQL is excluded from the `verifyPerms` block (`!isSqlOperation`) and handled solely by `verifyPermsAST`, which validates only the statement's tables and attributes — never the `operations` allowlist and never `requires_su`. A table-free statement gives the AST check nothing to validate.

This is the SQL-surface sibling of the known GraphQL ops-allowlist bypass.

### Scope

- Pre-existing behavior; matches the control flow prior to the `chooseOperation` authorization fix, so it is not a regression from that change. Deferred because enforcing gate 1 for SQL changes authorization outcomes for existing roles and needs its own change + release note.
- Documented in `DESIGN.md` (the `chooseOperation` section).

### Fix direction

Run gate 1 (`operations` allowlist + `requires_su`) for `sql` operations in addition to the AST table check, so the two checks are additive rather than exclusive.

Read server/serverHelpers/serverUtilities.ts around chooseOperation (264-266) and the chooseOperation section of DESIGN.md first. Trace the existing gate 1 and verifyPermsAST paths, then ensure SQL authorization applies both the operations/requires_su check and the AST table/attribute check. Completion also requires the scoped release note.

Written by the indexing model from the issue text.