AST driver rejects odd-length 0x hex literals that MySQL accepts (e.g. 0x711) #543

Description

The AST driver rejects 0x… hexadecimal literals that have an odd number of digits, which MySQL accepts.

MySQL treats an odd-length 0x value as having an extra leading 0, so 0x711 means 0x0711. The HEX_NUMBER case in WP_MySQL_On_SQLite::translate_token() (packages/mysql-on-sqlite/src/sqlite/class-wp-mysql-on-sqlite.php) turns 0x711 into x'711' without padding, and SQLite only accepts blob literals of even length.

Reproduction

SELECT HEX(0x711);

• MySQL: 0711
• AST driver: SQLSTATE[HY000]: General error: 1 unrecognized token: "x'711'"

It also breaks imports. A dump with a row like the one below fails in wp sqlite import --enable-ast-driver:

INSERT INTO `wp_posts` (`ID`, `post_title`, `post_name`) VALUES (51701, 0x711, 0x711);

Expected

Left-pad odd-length 0x… values to full bytes, so 0x711 becomes x'0711', the way #255 does for 0b… literals. The X'…' form should keep rejecting odd lengths, because MySQL rejects those too.

#255 left hex literals out because they "require to be byte-aligned also in MySQL". That holds for X'…', but not for 0x….

Context

We found this in WordPress Studio, where pulling a site from WordPress.com failed. The export wrote a post title of 0x711 unquoted, which is a separate bug in that exporter. In MySQL the statement still runs, but the SQLite import stops on it and rolls back. Plugin versions 2.2.13, 3.0.2, 3.1.0 and current trunk all have the same code.