WordPress install/init emits MySQL-only SQL the ePHPm tenant path rejects (multi-table DELETE, INSERT…ON DUPLICATE KEY UPDATE)

[luthermonson]

Found while standing up a live WordPress preview on ePHPm (per-site Turso, multi-tenant tenant path) via the db-wordpress drop-in. Core install populates the schema + default content and pages serve HTTP 200, but the installer's final step returns 500 and a theme block-pattern cache write fails on init.

Two MySQL-only statements the drop-in passes through unchanged, which the ePHPm tenant/Turso path rejects:

1. Multi-table DELETE (MySQL extension) — e.g.
   DELETE a, b FROM wp_options a, wp_options b WHERE ...
   (WP uses this to dedupe autoload options during install finalize.)

2. INSERT ... ON DUPLICATE KEY UPDATE — the upsert WP uses for the theme block-pattern transient cache on init.

Impact: install completes enough to serve (schema + content present), but the finalize step 500s and repeated init writes fail. Blocks clean automated seeding for the PR-preview use case.

Fix shape (drop-in translation layer):

• Rewrite multi-table DELETE a, b FROM t a, t b WHERE ... into a subquery/DELETE ... WHERE id IN (SELECT ...) form Turso accepts (or a two-statement equivalent).
• Translate INSERT ... ON DUPLICATE KEY UPDATE → SQLite INSERT ... ON CONFLICT(<key>) DO UPDATE SET ... (needs the conflict target; wp_options key is option_name).

Environment: ePHPm main @ 6175846 (per-site Turso, [server] preview=true, fpm_engine=pool), WordPress 7.0.4, PHP 8.5.7, db-wordpress drop-in in-docroot.