litewire rejects ORDER BY/LIMIT in subqueries and UPDATE/DELETE LIMIT — blocks ActionScheduler queue runner

[luthermonson]

While bringing up a plugin-heavy WooCommerce showcase on the embedded Turso engine, ActionScheduler's queue runner (bundled by WooCommerce and WPForms) fails at runtime:

UPDATE wp_posts SET post_password = '<claim>', post_modified_gmt = ..., post_modified = ...
WHERE post_type = 'scheduled-action' AND post_status = 'pending' AND post_password = ''
      AND post_date_gmt <= '<now>'
ORDER BY menu_order ASC, post_date_gmt ASC, ID ASC
LIMIT 25

litewire/Turso: SQL parse error: Expected: end of statement, found: ORDER — the embedded engine is not built with SQLITE_ENABLE_UPDATE_DELETE_LIMIT, so a trailing [ORDER BY] LIMIT on an UPDATE/DELETE is rejected.

The standard SQLite workaround is a rowid subquery:

UPDATE wp_posts SET ... WHERE rowid IN (SELECT rowid FROM wp_posts WHERE ... ORDER BY ... LIMIT 25)

But litewire's SQL parser also rejects LIMIT (and ORDER BY) inside ANY IN (SELECT ...) subquery — verified against the live engine:

SELECT ID FROM wp_posts WHERE ID IN (SELECT ID FROM wp_posts LIMIT 3)
-> SQL parse error: Expected: ), found: LIMIT
SELECT ID FROM wp_posts WHERE ID IN (SELECT ID FROM wp_posts ORDER BY ID LIMIT 3)
-> SQL parse error: Expected: ), found: ORDER

So the rewrite cannot be done in db-wordpress — both the source form and the natural workaround are blocked in litewire's parser. This needs a fix in litewire (accept ORDER BY/LIMIT in a parenthesized subquery, and/or UPDATE/DELETE ... LIMIT). Until then, ActionScheduler background processing (WooCommerce scheduled emails, report/lookup regeneration) does not run; the store front end, products, cart and orders are unaffected.

Impact: non-fatal, background only. Store renders and orders create normally.