docs(2meet-data-optimizer): ADR-004 search-index mode and 1.1.0 release notes

- ADR-004: HivePress / WooCommerce sites keep native meta as the source of truth and use flat tables as its search index; records the 2.1 write order, shadow_read, Promotion Guard, restore policy and router rules, with known limits
- CONTEXT.md Entity Bridge, BENCHMARK-SCALE.md front-end and write-chain measurements (dev36), CHANGELOG and readme for 1.1.0; version 1.1.0
- composer phpcs uses phpcs.xml like CI (was --standard=WordPress with 2312 false errors)
- Verify: composer phpcs (0); composer test; composer stan
- PR: PR-064

CONTEXT.md

@@ -135,6 +135,29 @@ Newer anti-EAV system (v2.5+) covering user, term, comment, and post entities vi
 The Entity Bridge and the Zone system coexist; the Sync Bridge's
 `is_owned_by_entity_bridge()` guard prevents duplicate writes.
 
+**Write order (v1.1.0).** In `dual_write` / `shadow_read` the Hook Bus pre-filters
+only decide the route and return `null`: WordPress writes native meta itself, and the
+flat value is then re-synced *from native* in `added_/updated_/deleted_{type}_meta`
+(priority 1) — `TMDO_Hook_Bus::sync_from_native()` reads the first native row with
+direct SQL; no native row → flat NULL. `aeav_only` keeps the pre-filter short-circuit.
+
+**shadow_read** reads native meta (WordPress meta cache) and compares a sample of reads
+with the flat value (`tmdo_shadow_compare_sample_rate`, default 0.1). Flat tables serve
+queries only: `TMDO_Post_Query_Router` is active from `shadow_read` up.
+
+**Search-index mode** (ADR-004). On HivePress / WooCommerce sites native meta is the
+source of truth and flat tables are its search index: `TMDO_Promotion_Guard` refuses
+`aeav_only` and cleanup there (post/user/term/comment with HivePress, post/user with
+WooCommerce), because both read meta with an empty key and WooCommerce updates stock
+and sales with direct SQL. Override: filter `tmdo_promotion_guard_allow`.
+
+**Post query router rules.** A query is rewritten only when the flat table returns
+what native `meta_query` would: every registered clause routable (else the whole query
+stays native), AND relation, one post type, column type matching the clause's CAST
+semantics, LIKE as `%esc_like%`. Meta ordering (the HivePress `_sort` NOT EXISTS/EXISTS
+shape, a named clause, `meta_key` + `meta_value_num`) is routed only as the sole
+`orderby` on a column that orders like native.
+
 ---
 
 ## Migration Phase (Strategy pattern)