docs(compat): record the non-autoloaded option as differentiator D4

[dknauss]

Why

Dan observed on live sites that Admin Menu Editor's option row can dominate wp_options and become an admin-load bottleneck. That checks out — it is known and acknowledged upstream — and Maestro's storage model is the direct counter-position. But that position was recorded nowhere except one cell of the 2026-08-01 architecture table, and the feature sweep was scoped to skip it.

What changed

PRIOR-ART-admin-menu-editor.md — new D4 in Differentiate. The storage-row consequence of the existing V2 finding ("do not adopt a stored full-tree"), not a new claim:

• AME's ws_menu_editor is autoloaded, so every request the site serves — front end included, where the data is never used — pays to fetch and unserialize it, and it grows with the whole admin menu (every installed plugin adds to the stored tree) rather than with what the user edited.
• Evidence is upstream, not inferred. Elsts confirms the autoload behavior in a wordpress.org thread and declines to flip it because non-autoloaded "would mean an additional SQL query on every admin page." Three size mitigations across 2.5 (2017 compress), 2.11 (2020 + zlib), 2.27 (2025 "Optimize menu configuration size") per the Pro changelog — three rounds over eight years is what makes it structural rather than a bug.
• Maestro's side with the measured numbers from docs/performance/config-size-and-page-load.md, and the trade named honestly: non-autoloaded costs 1 extra admin-page query — exactly Elsts' objection — taken because it is admin-only, memoized once per request, zero with a persistent object cache, while public traffic pays nothing.
• Flagged as the strongest of D1–D4 for positioning because it is the only one a third party can verify without installing either plugin: wp option list --autoload=on.

Feature-sweep todo — carve-out so the matrix carries it. The todo put storage entirely out of scope, so the sweep would have missed this. Format stays out (architecture, already answered); the consequences are in, because AME's two Settings-tab toggles — "Compress menu configuration data" and "Optimize menu configuration size" — are user-facing features. They earn rows, landing deliberately-not: a config that is sparse and outside alloptions never needs a compression toggle.

class-config.php — stale comment. The MAX_CONFIG_BYTES docblock said the cap protects "every autoloaded read of it," contradicting the update_option( …, false ) two methods below. Now says admin-request read, and states that the option is never part of alloptions.

Open evidence question, tracked

D4's autoload flag comes from the author's reply and the changelog, not from a source read — the 1.15.1 spike recorded the storage format but not the update_option call. The sweep already opens the free zip, so the todo now carries confirming that call as a check, which upgrades the row to source-read.

Verification

Comment-only code change: php -l clean, phpcs --standard=phpcs.xml.dist includes/class-config.php clean (1/1, 0 errors). No behavior change, so no test run beyond lint.

Not done deliberately

README.md and readme.txt already state the facts accurately (README: "Not autoloaded, so it adds nothing to alloptions"; readme.txt 134–135). The gap was competitive framing, not accuracy — and naming a competitor's performance problem in a wordpress.org readme cuts against directory norms. Happy to sharpen the public copy without naming AME if wanted.

🤖 Generated with Claude Code