[WaylandYang]

Fixes the schema-sync half of #316, found by running the engine's own live test against a real MySQL 8.4 and MariaDB 11.4 (containers over an SSH tunnel).

fetch_schema could not read information_schema.columns on a real server at all:

error occurred while decoding column 0: mismatched types;
Rust type `alloc::string::String` (as SQL type `VARCHAR`) is not compatible with SQL type `VARBINARY`

Since MySQL 8.0 information_schema is a set of views over the data dictionary, and its string columns come back as VARBINARY through the binary protocol. sqlx's strict decoding refuses to read that into a String. The raw SQL looks fine from the CLI — the CLI does no typed decode — so this only surfaces against a live server through the driver, which is exactly the gap #316 named.

The fix wraps each selected column in CAST(... AS CHAR). Harmless on MariaDB, one statement for both.

Verified on both servers with the gated live test a_live_server_answers_with_typed_values (UTOPIA_TEST_MYSQL_URL=…):

• MySQL 8.4.11 — schema reads, and the value round-trip returns typed values: BIGINT UNSIGNED at the u64 ceiling, DECIMAL as a number, TINYINT(1) as a bool, an all-NULL row as JSON nulls.
• MariaDB 11.4.13 — same, and this is the run that exercises the timeout fallback: SET SESSION max_execution_time errors with 1193 and the engine falls through to max_statement_time. On MySQL the reverse holds (max_statement_time → 1193), so the two spellings are confirmed against the two servers they target.

🤖 Generated with Claude Code