ext-mysql2: prepared-statement param binding races — params matched against the wrong statement

[proggeramlug]

Env: perry 0.5.1512 built from main@6173ff9f6 (single cargo invocation: -p perry -p perry-runtime-static -p perry-stdlib-static -p perry-ext-mysql2 …), macOS arm64. MySQL 8.0.46. Found in the MB24 Phase-0 dependency spike.

Repro (mysql2/promise against any MySQL 8):

import mysql from "mysql2/promise";
const pool = mysql.createPool({ /* env */ });
await pool.query("DROP TABLE IF EXISTS t");
await pool.query("CREATE TABLE t (id INT AUTO_INCREMENT PRIMARY KEY, name VARCHAR(50), cents INT)");
await pool.execute("INSERT INTO t (name, cents) VALUES (?, ?)", ["x", 100]);
const [r] = await pool.execute("SELECT * FROM t WHERE id = ?", [1]);

Actual: non-deterministic; the param list is applied to the wrong prepared statement. Two observed shapes of the same failure across runs:

• Query failed: … prepared statement expected 1 parameters but 0 parameters were provided (sqlx_mysql::connection::executor:131) — SELECT prepared with 1 placeholder, params dropped;
• … expected 0 parameters but 2 parameters were provided — the 2-param INSERT matched against a previous 0-param statement (the DROP/CREATE).

Same statements succeed on other runs — looks like a statement-cache/queue association race in the ext, not a per-statement-type gap. pool.query("SELECT 1") with no params is always fine.

Expected: params bind to the statement they were passed with, as on Node mysql2.

Full repro file: mobilitybroker24/monorepo spike/tests/05-mysql.ts (+ minimal versions used for this report).

[proggeramlug]

Closed by #8765, landed on main via #8778 (squash 1f5c3bb80).

That PR was landed through a batch wrapper PR rather than merged directly, so GitHub's close keyword never fired at merge time — its mergedAt is null even though the work is on main. Verified before closing: changelog.d/8765-mysql2-request-scoped-statements.md is present and perry-ext-mysql2 --lib passes 10/10 on the merged result.