fix(editor): close SQL guard bypasses in the query editor

[notSumit25]

A CHAT_EDITOR (non-admin) user could delete or overwrite every row in any table by wrapping the write in a CTE. WITH x AS (DELETE FROM t RETURNING *) SELECT * FROM x parses as a Select, so classification returned read-only and returned before the admin check ever ran. PostgreSQL executes data-modifying CTEs for real. Verified end to end: 3 rows -> 0, success:true, no confirmation prompt, logged as an ordinary EDITOR_QUERY_EXECUTED / SUCCESS.

• classifyStatement now walks the parse tree for data-modifying CTEs and SELECT ... INTO (detectSelectWrite), with a text backstop (detectHiddenWrite) so an unparseable variant fails closed instead of reaching isReadOnlyQuery, which reports anything starting with WITH as safe.
• READ_ONLY_ONLY contexts now open read-only JDBC sessions, so the database refuses the write even when classification is wrong. Classification is a parser heuristic; this is what keeps the next parser gap from being data loss. HikariCP resets the flag on return to the pool, verified, so it cannot leak into an admin's later write.
• Row caps are enforced with setMaxRows instead of a \blimit\s+\d+ text match that hit inside comments, string literals and subqueries. An inner LIMIT returned 200k rows against a 1,000 cap, into an unbounded ArrayList and an unvirtualized table.
• Cancel terminates the query instead of only aborting the HTTP request, which left the statement holding one of the pool's 10 connections. The client sends an executionId, RunningQueryRegistry maps it to the backend session pid, and the new cancel endpoint kills exactly that session, scoped to the connection and the user who started it. The previous UI behavior killed every active query on the connection, including other users' work.
• Fix pg_terminate_backend binding: setLong sent bigint, so PostgreSQL found no matching overload and every kill failed, including the Active Queries screen's own button.
• Editor timeout 600s -> 240s, under nginx's 300s proxy_read_timeout, so a slow query reports a real error rather than an opaque 504 while still running.
• Rate-limit /api/connections/*/query (30r/m + burst 20, 429 on reject).

QueryExecutionPolicyServiceTest stubbed isReadOnlyQuery to always return false — the opposite of what the shipped providers do for WITH — so it asserted behavior no deployment had, and withInsert_isTreatedAsMutation passed because of the stub. It now uses a real MySQLQueryExecutionProvider, plus 12 regression tests covering each bypass and the reads that must keep working.

[venkateshsakamuri-lab]

@notSumit25 code scan failed. Pl check and fix it.