fix(mcp): classify compound routines as ddl

[Stiwar0098]

Closes #384

Summary

• Classifies compound MySQL/MariaDB \CREATE PROCEDURE\, \CREATE FUNCTION\, \CREATE TRIGGER\, and \CREATE EVENT\ statements as \ddl\ in MCP activity.
• Keeps obvious trailing payloads after routine bodies fail-closed as \unknown\.
• Adds regression coverage for routine classification and local \.opencode/\ ignore handling.

Review notes

• GitNexus affected-scope check: low risk, 0 affected processes.
• Fresh reliability review: no PR-opening blockers; warning remains for nested compound blocks being potentially classified as \unknown\.

Test plan

• Not run: maintainer explicitly requested not to run a build.

[debba]

Took a look at this. The core approach is sound — moving the routine check ahead of the multi-statement guard so the ; inside a BEGIN ... END body don't get the whole thing flagged as unknown. I traced the consumers in mcp/mod.rs (the read-only gate at line 913 and the approval gate at line 933) and both key off kind != "select", so ddl and unknown are treated the same way for enforcement. That means the new path only ever returns ddl for a CREATE, never downgrades anything to select, and stays fail-closed. No security concern here.

Two small things, both about classification accuracy rather than safety:

1. is_create_compound_routine runs on the raw uppercased SQL (trimmed_upper), while the rest of classify_query_kind works off strip_strings_and_comments. So split("BEGIN"), rfind("END") and the trailing-statement scan all see string literals and comments as if they were code. A legit routine whose body has something like SELECT 'END; foo' will get read as a trailing statement and fall back to unknown. It fails closed, so nothing breaks, but the audit query_kind ends up wrong. Worth running this on the already-stripped string instead.

2. without_terminal_semicolon.ends_with("END") isn't word-boundary aware, unlike contains_keyword. A malformed CREATE FUNCTION ... BEGIN RETURN total_spend (no real END, but SPEND ends in "END") would slip past that check. Edge case and it's still gated as a write, so cosmetic, but the boundary check would be more consistent with the rest of the file.

The nested BEGIN ... END limitation you already called out is fine — it resolves to unknown, which is the safe direction.

Nothing blocking. Good to merge as is; the two notes above are optional cleanups.