fix(2meet-data-optimizer-hivepress-addon): with an object cache, keep HivePress transients out of wp_options entirely

- On a cache miss the filter fell back to get_option(): with the values now written to the cache, the option is absent, so WordPress added its name to `notoptions` for good (dev36: +1,000 entries for 1,000 posts, one array loaded on every miss); a hit kept the old row in the options cache group with no expiry, which slowed the selective Redis flush (8.9 s, BUSY). The cache is now the only store for reads and deletes; old rows wait for cleanup-hp-transients --options. Without an object cache nothing changes.
- Verify: HivepressTransientFilterTest (2 RED before); dev36 notoptions 210 → 210 over 1,000 posts (was 128 → 1,128)
- PR: PR-089c

CHANGELOG.md

@@ -20,10 +20,12 @@ Released with 2meet-data-optimizer 1.2.0 (hardening 2.2).
 - With a persistent object cache (`wp_using_ext_object_cache()`), the
   transient filter keeps HivePress's per-post transient pairs in the
   `tmdo_hp_transient` cache group instead of `wp_options`, where they piled
-  up (1.15 M pairs on dev36). Reads fall back to `wp_options` for values
-  written before; deletes clear both. Without an object cache nothing changes.
-  After upgrading, remove the rows left behind with core's
-  `wp tmdo cleanup-hp-transients --options --confirm`.
+  up (1.15 M pairs on dev36). The cache is then the only store: rows written
+  before are neither read nor deleted (HivePress rebuilds those caches once),
+  because a `get_option()` miss adds the name to WordPress's `notoptions` for
+  good and a hit keeps the old row in the `options` cache group with no expiry.
+  Without an object cache nothing changes. After upgrading, remove the rows
+  left behind with core's `wp tmdo cleanup-hp-transients --options --confirm`.
 
 ### Fixed