feat(runtimes): register kimaki + opencode worktree runtime signatures

[chubes4]

Summary

Publishes wp-coding-agents' knowledge of kimaki + opencode env-var conventions as a Data Machine Code filter callback (datamachine_code_worktree_runtime_signatures), so DMC can capture worktree origin-session metadata generically — without naming any specific coding-agent runtime in its own source.

Sibling to Extra-Chill/data-machine-code#416 and direct execution of Extra-Chill/wp-coding-agents#131.

Chosen mechanism: B (new dedicated mu-plugin file)

The issue's ## Mechanism choice listed three options; I picked B (new mu-plugin file wp-coding-agents-runtimes.php) rather than the issue's preferred C (wp option patch insert). Rationale:

• C is blocked by the consumer. DMC#416's acceptance criteria specify a filter-only API (apply_filters( 'datamachine_code_worktree_runtime_signatures', [] )) with no get_option fallback. Writing to wp_options would land data DMC never reads. The issue body explicitly allows the C → B fallback when "DMC#416 ships filter-only" — that's the case here.
• C also has known operational hazards. 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." The same constraint applies to install-time signature writes.
• A would mix two unrelated concerns under a -channels.php filename. Worktree attribution is not a CLI channel; it's an env-var contract for a different filter consumer with different lifecycle. Folding them in would make the file name lie.
• B mirrors the existing lib/cli-channel.sh pattern exactly — marker-delimited blocks, idempotent register/unregister, dry-run support, same scaffold style — so future maintainers find one shared mental model.

The mu-plugins/ surface growth is a real-but-small paper cut. Consolidating the two wp-coding-agents mu-plugins into one shared file is a clean follow-up that does not need to ride this PR.

Per-runtime changes

File	Function added	Called from	Signature
bridges/kimaki.sh	_kimaki_register_runtime_signature	bridge_install + bridge_sync_config (alongside the existing _kimaki_register_cli_channel)	{"session_id":"KIMAKI_SESSION_ID","thread_id":"KIMAKI_THREAD_ID","thread_url":"KIMAKI_THREAD_URL"}
runtimes/opencode.sh	_opencode_register_runtime_signature	runtime_install + upgrade.sh::remove_legacy_opencode_wrapper_phase (the existing upgrade-time entry point that already sources runtimes/opencode.sh)	{"session_id":"OPENCODE_SESSION_ID","run_id":"OPENCODE_RUN_ID"}

Shared helper

New lib/runtime-signature.sh mirrors lib/cli-channel.sh:

• runtime_signature_register <runtime_id> <signature_json> — upsert a runtime's marker-delimited block in $SITE_PATH/wp-content/mu-plugins/wp-coding-agents-runtimes.php.
• runtime_signature_unregister <runtime_id> — remove a runtime's block, preserving siblings.
• runtime_signature_ensure_mu_plugin_file / runtime_signature_mu_plugin_path — scaffold + path helpers.

Sourced from both setup.sh and upgrade.sh (added to the existing for lib in …; do source …; done loops).

Layer purity

No DMC-specific naming leaks into the registration: datamachine_code_worktree_runtime_signatures is the filter name DMC#416 defines, not a DMC implementation detail. The signatures themselves are pure runtime-vendor data — kimaki and opencode are the brand names this layer is supposed to own per the platform's layer-purity rule (codified in RULES.md). The mu-plugin scaffold's only DMC reference is a single comment citing the issue number for traceability; nothing in the executable PHP couples wp-coding-agents to DMC internals.

Confirmation: grep -riE 'datamachine_code|DMC' lib/runtime-signature.sh bridges/kimaki.sh runtimes/opencode.sh returns only the filter name + comment citations, no implementation coupling.

Documentation

New "Worktree Session Attribution (Runtime Signatures)" section in README.md after "Outbound Dispatch":

• Explains the layering: wp-coding-agents owns the env-var → field map, DMC consumes it generically.
• Documents the mu-plugin file, the marker-block layout, and a per-runtime/per-subkey table.
• States explicitly that DMC shipping kimaki/opencode-specific code is a layer violation to be filed against DMC, not patched here, matching the wording the issue requested.

Verification

• bash -n parses cleanly on all modified scripts (lib/runtime-signature.sh, lib/cli-channel.sh, bridges/kimaki.sh, runtimes/opencode.sh, setup.sh, upgrade.sh).
• New tests/runtime-signature.sh covers: scaffold creation, php -l lint of the generated PHP, idempotent re-register, sibling registration, mutation-replaces-just-the-runtime's-block, unregister-preserves-siblings, and a php-execution end-to-end assertion that apply_filters( 'datamachine_code_worktree_runtime_signatures', [] ) returns the expected shape. All 14 assertions pass.
• All other existing tests still pass (tests/datamachine-kimaki-adapter.sh, tests/homeboy-components.sh, tests/kimaki-session-helper-smoke.sh, tests/opencode-local-plugin-path.sh, tests/opencode-wrapper-removal.sh, tests/path-helpers.sh, tests/post-upgrade-restore.sh, tests/repair-opencode-json.sh).
• Idempotency: re-running register with the same signature is a no-op (md5 unchanged); re-running with a different signature mutates only that runtime's block.
• Uninstall removes the registration cleanly; the helper exits early when SITE_PATH is unset or the file is missing.
• No CHANGELOG.md or VERSION edits.

Pre-existing snapshot drift (unrelated to this PR)

tests/bridge-render.sh shows kimaki-launchd snapshot drift on this branch — but also on bare main (verified with git stash && bash tests/bridge-render.sh). It is a PATH-ordering artifact in the launchd plist <PATH> element, sensitive to the test environment's PATH at render time. Not caused by this PR; flagging only so the PR review does not block on it.

Dependency note

This PR depends on Extra-Chill/data-machine-code#416 landing first. The filter datamachine_code_worktree_runtime_signatures must exist in DMC before this registration is functional.

The DMC PR is not yet open at the time of writing (verified via gh pr list --repo Extra-Chill/data-machine-code --state all). Both PRs can open and be reviewed in parallel — this PR is mergeable independently because the registration is a harmless add_filter callback on a host without a consuming filter. It is just not functional until a DMC release containing #416 deploys.

The signature shapes registered here match #416's ## Proposed shape example payload verbatim:

{
  "kimaki":   { "session_id": "KIMAKI_SESSION_ID", "thread_id": "KIMAKI_THREAD_ID", "thread_url": "KIMAKI_THREAD_URL" },
  "opencode": { "session_id": "OPENCODE_SESSION_ID", "run_id": "OPENCODE_RUN_ID" }
}

Closes #131

cc <@532385681268408341>