refactor(channels,runtimes): move mu-plugin file registrations to wp_options where safe

[chubes4]

Summary

wp-coding-agents currently writes two mu-plugin files at install/upgrade time:

• wp-content/mu-plugins/wp-coding-agents-channels.php — registers CLI channels for agents/dispatch-message (PR feat(bridges): register CLI-channel config for agents/dispatch-message #130).
• wp-content/mu-plugins/wp-coding-agents-runtimes.php — registers worktree runtime signatures (PR feat(runtimes): register kimaki + opencode worktree runtime signatures #132).

This is the architectural inverse of the WordPress idiom: plugin-managed configuration normally lives in wp_options, not in mu-plugins/. Mu-plugins are reserved for site-operator-owned policy that cannot be deactivated. Third-party-managed config there:

• Pollutes the mu-plugins/ surface that audit tooling, backup plugins, and security plugins expect to be operator-controlled.
• Is invisible to the WP admin UI (which can inspect options but not auto-loaded plugins).
• Tripped over file permissions immediately (see fix(lib): mu-plugins written by lib/cli-channel.sh and lib/runtime-signature.sh land as 0600, breaking PHP-FPM read #133) — a problem that wouldn't exist for option writes because PHP-FPM owns the database write path end-to-end.

DMC's runtime registries (CliChannelRegistry, the dispatch-message handler filter, the worktree-signature filter) already read from apply_filters( ... ) AND get_option( ... ) in a dual pattern — meaning the option-based path is supported in DMC today. Only the wp-coding-agents installer chose the mu-plugin path.

Why this wasn't done in the original PRs

Per #131's chosen-mechanism rationale (which I'm reproducing here from the PR body for context):

lib/cli-channel.sh:21 documents the prior rejection of wp option writes for the parallel CLI-channel registry: "DB writes there race against multisite + Redis caching and have been a source of intermittent install failures historically."

That's a real constraint. It's also one that can be fixed with care — wp option update works on multisite + Redis when invoked correctly. The historical install failures referenced in that comment are worth investigating before this refactor lands.

Proposed work

1. Investigate the cited historical install failures. Find the actual symptoms (git-blame the comment, dig for prior install reports). Are they reproducible? Were they specific to a Redis configuration that's been since fixed? Was the issue actually wp option update itself or an unrelated install-time race?
2. If the option path is genuinely safe today, rewrite both lib/cli-channel.sh and lib/runtime-signature.sh to use wp option patch insert/delete instead of the mu-plugin file rewrite.
3. Migration path: on upgrade, if the legacy mu-plugin file exists, parse its marker blocks, write the equivalent entries to wp_options, then delete the file. Symmetric to how the agent-ping legacy retirement was handled — clean on-read migration with no script.
4. If the option path is still unsafe (or partially so — e.g. safe for channels but risky for signatures, or vice versa), document the constraints clearly and stay on the mu-plugin path for whichever surface needs it. File a follow-up on the constraint.

Acceptance criteria

• If the refactor proceeds: both lib/cli-channel.sh and lib/runtime-signature.sh write to wp_options instead of wp-content/mu-plugins/.
• Migration handles existing installs without losing registered channels or signatures.
• No regression in idempotency, dry-run support, or test coverage.
• Documentation in README.md updated.
• No CHANGELOG.md / VERSION edits.

If the refactor does NOT proceed because the option path is genuinely unsafe:

• The investigation findings are documented in a comment on this issue.
• lib/cli-channel.sh:21's comment is updated to be specific about which install configurations the prohibition covers, so future contributors don't perpetually re-debate.
• This issue closes with wontfix and a link to the documented constraint.

Related

• fix(lib): mu-plugins written by lib/cli-channel.sh and lib/runtime-signature.sh land as 0600, breaking PHP-FPM read #133 (mu-plugin perms bug) — heals the most acute symptom of the mu-plugin path. If fix(lib): mu-plugins written by lib/cli-channel.sh and lib/runtime-signature.sh land as 0600, breaking PHP-FPM read #133 lands first, this refactor becomes lower priority.
• DMC #412 — generic CLI transport runtime that reads via filter + option (dual pattern).
• DMC #416 / wp-coding-agents feat(runtimes): register kimaki + opencode env-var signatures for DMC worktree attribution #131 — worktree runtime signatures using the same dual pattern.

Priority

Low. The mu-plugin path works once #133 fixes perms. This is architectural cleanup, not a bug fix. File-and-park unless someone wants to do the investigation work in step 1.