fix(db): MySQL 结果列字符集未知时按 UTF-8 兜底解码，修复文本列显示为二进制

[feigeCode]

现象

连接某些 MySQL 兼容实现 / 中间代理时，结果网格把文本列显示成「二进制 · N B」：表结构、自定义 SQL 都会出现，UNION ALL 这类把字符串字面量和表列混在一起的查询尤其明显。

根因

• 这类服务端在结果列元数据里不下发字符集：collation_id = 0、charset = unknown（正常 MySQL 给 255/45，character_set_results=binary 时给 63）。
• crates/db/src/mysql/codec.rs 的 decode_character 在 column_text_decoder 取不到 decoder 时一律降级为 DbValue::Binary，网格于是显示二进制 + hex。
• 实际字节是合法 UTF-8，所以问题在解码降级，不在数据。
• 表数据查询有 schema 纠偏（normalize_table_query_result）能救回这类列；但 information_schema 元数据、自定义 SQL、UNION ALL 结果不走这条纠偏，仍然显示二进制。

修复

字符集未知（collation 0 / 未映射）时按严格 UTF-8 兜底解码，判定复用 decode_untyped_bytes 已有的 is_valid_utf8_text（合法 UTF-8 且不含控制字符）：

• 能解出文本 → DbValue::Text
• 解不出（非法 UTF-8、含控制字符）→ 仍保留二进制 sidecar 与 hex 显示
• wire 上已声明 collation 63 的字节列、已声明字符集的列 → 行为不变

改动集中在 crates/db/src/mysql/codec.rs（+71 行，含 3 个回归测试）。

验证

真机链路：本机 MySQL 8.0.45 + 一个透明代理（只把列定义包里的 character_set 改写成 0，协议与数据都来自真实 MySQL）复刻现场。

• 修复前：文本列进入 binary_cells，网格显示二进制
• 修复后：表数据 / UNION ALL（字面量列 + 多分支 + 中文 IN 列表，即现场查询形态）/ information_schema 三条路径 binary_cells = 0，文本正常；000102FF、FF00 这类真二进制仍是二进制
• cargo test -p db --lib 全绿；cargo clippy -p db --all-targets 无新增告警

取舍

字符集未知的服务端上，内容是「可打印 ASCII」的真二进制列会显示为文本（此前显示二进制）。X'0102' 这类含控制字符的仍按二进制走；若要严格区分，可再按 BINARY_FLAG 收窄。