wpress import fails with "Could not execute statement: INSERT INTO `wp_wfconfig`" for sites using Wordfence

### Quick summary

Importing an `.wpress` (All-in-One WP Migration) backup from any site that has Wordfence installed fails partway through. The bundled sqlite-database-integration AST translator does not recognize MariaDB's bare `0x` empty-BLOB literal, which Wordfence's `wp_wfconfig` table emits for empty config values. The import aborts on the first one and leaves the SQLite DB partially populated.

Filed upstream with reproducer: [WordPress/sqlite-database-integration#403]().

### Steps to reproduce

1. On a source WordPress site that uses Wordfence, generate an All-in-One WP Migration export (`.wpress`).
2. In Studio, create a new site (or use an existing one).
3. Run `studio site import path/to/your-backup.wpress` (or use the GUI's Import option).

### What you expected to happen

The wpress is restored end-to-end: every table imported, theme/stylesheet set, plugins activated, site loads correctly at the local URL.

### What actually happened

The CLI errors out partway through:

```
Database import failed: Error: Could not execute statement:
INSERT INTO `wp_wfconfig` VALUES ('bannedURLs', 0x, 'yes')
```

Inspecting the SQLite DB after the abort:

* Schema is fully created.
* Tables alphabetically up to and including `wp_wfconfig` got partial data (`wp_posts`, `wp_postmeta`, `wp_options`, `wp_users` are populated).
* Tables alphabetically after `wp_wfconfig` (Wordfence diagnostic tables, WooCommerce, WP Rocket, WP Mail SMTP) have no rows.
* ai1wm's post-import option pass never ran, so `wp_options.template`, `stylesheet`, and `active_plugins` are empty - the front-end loads with the default theme and zero plugins active.

### Impact

Some (< 50%)

(Affects every user attempting `.wpress` import from a site with Wordfence installed - Wordfence is widely used, but only `.wpress` users hit this code path.)

### Available workarounds?

Yes, difficult to implement

`.wpress` is uncompressed, so `database.sql` lives in plain bytes inside the archive. A same-byte-count binary patch fixes it without re-packing:

```python
path = "/path/to/your-backup.wpress"
data = open(path, "rb").read().replace(b",0x,", b",'',")
open(path, "wb").write(data)
```

After patching, `studio site import` runs to completion. Requires Python and shell access; not something a typical Studio user would do unaided.

### Platform

Mac Silicon

### Logs or notes

**Cause**

The AST translator (`wp sqlite import --enable-ast-driver`, in the bundled sqlite-database-integration plugin pinned at `v3.0.0-rc.3`) doesn't model MariaDB's bare `0x` token (a hex literal with zero hex digits, valid in MariaDB/MySQL as an empty binary string). Hex literals with content (e.g. `0xDEADBEEF`) translate fine; only the empty form errors.

**Suggested fix in Studio**

Once [WordPress/sqlite-database-integration#403]() is resolved, bump `SQLITE_DATABASE_INTEGRATION_VERSION` in `apps/studio/src/constants.ts`. Same path that was used for Automattic/studio#2302 → v2.2.17 → [#2512]().

If a faster interim fix is wanted, [`WpressImporter.prepareSqlFile()`]() already does one regex pass for the SERVMASK prefix ([line 436]()). A second same-byte regex (`/(?<=[,(])\s*0x\s*(?=[,)])/g → "''"`) added inside the same `rl.on('line', ...)` handler would unblock wpress imports for the affected user population without waiting on the upstream release.

**Environment**

* Studio 1.8.0
* sqlite-database-integration v3.0.0-rc.3 (current pin)
* Source DB: MariaDB 11.4.7
* All-in-One WP Migration 7.105

Read apps/cli/lib/import-export/import/importers/importer.ts, especially WpressImporter.prepareSqlFile() and its existing SERVMASK regex, then check apps/studio/src/constants.ts and upstream issue WordPress/sqlite-database-integration#403. Verify the chosen fix against a Wordfence .wpress backup and confirm the import completes with the post-import options and plugins restored.

Written by the indexing model from the issue text.