[P1][security] `read_only` profile flag is UI-only — backend executes DML/DDL unrestricted (FR-1.2.7)

[EVWorth]

Context

DESIGN_REQUIREMENTS §FR-1.2.7 acceptance: "Per-connection toggle to prevent any write operations (INSERT, UPDATE, DELETE, DROP, etc.); visual indicator when active".

Problem

ConnectionProfile.read_only is shown in the UI, persisted, and listed — but QueryExecutor::execute_owned routes every statement (including DROP/DELETE/TRUNCATE) straight to MySQL. No grep -n "read_only" src-tauri/crates/mas-core/src/query/ match. A user toggling Read-only mode and Ctrl+Enter-ing a destructive statement watches it run. The visual indicator half of the spec is also missing — no lock badge on the connection tab, no override-on-write confirmation.

Files

• src/types/index.ts:19
• src-tauri/crates/mas-core/src/models/connection.rs:40, 63
• src-tauri/crates/mas-core/src/query/executor.rs:31-97
• src/components/connection/ConnectionDialog.tsx:500-510

Repro

1. Create profile with read_only = true.
2. Connect. Type DROP TABLE users;, Ctrl+Enter.
3. Observe: table is dropped.

Expected

Backend returns Err("Connection is read-only: <statement>"), frontend surfaces the error, no data lost. With read_only=false, same query runs unchanged.

Proposed fix

Scope M. In execute_owned, look up profile.read_only via the connection manager; if true and SQL contains a non-SELECT statement, return CoreError::ReadOnlyViolation. Frontend: lock badge next to connection name; confirmation dialog on non-SELECT attempt while read_only.

Acceptance

Connecting with read_only=true and executing DROP TABLE users is rejected by the backend and surfaced in the UI.

Needs human verify

Yes.