fix(sql): the destructive-query detector misses non-Latin names, MySQL DELETE forms, WITH ... DELETE, EXPLAIN ANALYZE and DROP COLUMN #1770

Problem

`DestructiveSqlDetector.inspect` (lib/core/database/destructive_sql_detector.dart) decides whether the confirmation dialog appears. Its regexes were run on these inputs, and no confirmation would be shown for:

• Non-Latin identifiers (names are `[a-zA-Z0-9_]+`): `DROP TABLE "заказы"`, `DROP DATABASE склад`, `TRUNCATE "таблица"`. `DROP TABLE public.заказы` is detected, but the target is reported as `public`.
• MySQL `DELETE` forms: `DELETE IGNORE FROM t`, `DELETE LOW_PRIORITY FROM t`, `DELETE t1 FROM t1 JOIN t2 ...`. The `UPDATE` regex accepts `LOW_PRIORITY|IGNORE`, the `DELETE` one does not.
• PostgreSQL: `WITH x AS (...) DELETE FROM t` and `EXPLAIN ANALYZE DELETE FROM t` (which really deletes). The regexes are anchored at the start of the statement.
• Not a covered category at all: `ALTER TABLE ... DROP COLUMN` (loses data), `DROP INDEX/TYPE/FUNCTION/ROLE/USER`, `DROP ... CASCADE`.

Fix

• Use a Unicode-aware identifier pattern (`[\p{L}\p{N}_$]+` with `unicode: true`) or a quoted-identifier rule that takes everything between the quotes.
• Allow the MySQL modifiers (`LOW_PRIORITY`, `QUICK`, `IGNORE`) and the multi-table `DELETE t1 FROM` form.
• Look through a leading `WITH (...)` list and an `EXPLAIN [ANALYZE]` prefix before matching.
• Add `ALTER TABLE ... DROP COLUMN` and the other `DROP` kinds (a new type, risk HIGH).
• Tests with these exact statements.

Found in the review of the SQL safety layer.