GHSA-r3rv-jm3r-62q2

### Description When escaping string and binary parameters for the text protocol, the connector always escaped the quote character with a backslash, without ever consulting the session's NO_BACKSLASH_ESCAPES SQL mode. The server status flag was declared (STATUS_NO_BACKSLASH_ESCAPES) but never read. Under a server or session running with NO_BACKSLASH_ESCAPES, the backslash is an ordinary character and the quote must be escaped by doubling it. The escaped value produced by the connector therefore closed the string literal, and a value passed through a placeholder was interpreted as SQL. All text-protocol escaping entry points were affected, including Connection.escape(). ### Impact An attacker able to influence any value the application passes as a query parameter could execute arbitrary SQL with the privileges of the application's database user: read, modify or delete any data reachable by that connection. Exposure requires a deployment where NO_BACKSLASH_ESCAPES is enabled — server-wide, through the connector's sessionVariables / initSql options, or by an application-issued SET sql_mode. It is not implied by the ANSI, ORACLE or TRADITIONAL compound modes on MariaDB 11.4, so it has to be set deliberately. Where it is enabled, no unusual application code is needed: the standard placeholder API is the injection point. execute() and batch() are not affected: the binary prepared-statement and bulk protocols send parameter values out of band. ### Resolution The escaping routines now branch on the session status flag, doubling the quote and leaving the backslash untouched when NO_BACKSLASH_ESCAPES is set ### Workarounds Use execute() or batch(), or do not enable NO_BACKSLASH_ESCAPES, until upgraded. ### Credit Reported by fg0x0.