feat(runtimes): register kimaki + opencode env-var signatures for DMC worktree attribution

[chubes4]

Summary

Sibling to Extra-Chill/data-machine-code#416. DMC's worktree-attribution code is being made runtime-agnostic — the env-var → key mapping that today hardcodes KIMAKI_SESSION_ID, OPENCODE_RUN_ID, etc. moves out of DMC into a filter (datamachine_code_worktree_runtime_signatures). This issue tracks wp-coding-agents owning that registration, because wp-coding-agents is the layer that knows about kimaki and opencode — DMC does not.

Why this lives here

Per the platform's Layer purity rule (now codified in RULES.md):

The integration plugin (e.g. wp-coding-agents) is the only place where vendor-specific names live.

wp-coding-agents already installs kimaki and opencode. It already knows their env-var conventions (look at the existing systemd units it writes — they pass KIMAKI_SESSION_ID and friends into the spawned process). Registering the env-var → field map is just publishing that knowledge as a filter callback so DMC can consume it without naming the brands itself.

Proposed change

Add a small PHP shim — like the existing wp-coding-agents-channels.php mu-plugin written by bridges/kimaki.sh — that registers the runtime signatures:

```php
add_filter( 'datamachine_code_worktree_runtime_signatures', static function ( array $signatures ): array {
// BEGIN runtime:kimaki
$signatures['kimaki'] = [
'session_id' => 'KIMAKI_SESSION_ID',
'thread_id' => 'KIMAKI_THREAD_ID',
'thread_url' => 'KIMAKI_THREAD_URL',
];
// END runtime:kimaki

// BEGIN runtime:opencode
$signatures['opencode'] = [
    'session_id' => 'OPENCODE_SESSION_ID',
    'run_id'     => 'OPENCODE_RUN_ID',
];
// END runtime:opencode

return $signatures;

} );
```

Mechanism (open question to resolve in the PR):

• Option A: Extend the existing wp-coding-agents-channels.php mu-plugin to also register runtime signatures — keeps everything wp-coding-agents writes in one place. Pros: one file. Cons: file is named -channels.php but does more than channels now.
• Option B: A new mu-plugin file (wp-coding-agents-runtimes.php) dedicated to runtime registration. Pros: clean separation of concerns. Cons: more mu-plugins.
• Option C (preferred): A separate `wp option patch insert` pair, one per runtime, into a new option key like `datamachine_code_worktree_runtime_signatures` — DMC then reads from `apply_filters` + `get_option` (same dual pattern as the CLI channel registry). This matches the direction the channels registration is heading anyway (see the related mu-plugin → wp_options paper cut already noted) and avoids growing the mu-plugins/ surface.

Pick the mechanism in the PR description with a brief rationale.

Per-bridge wiring

Update the relevant installer scripts so registration happens at install/upgrade time and is removed on uninstall:

• runtimes/opencode.sh — registers `opencode` signature.
• `bridges/kimaki.sh` — registers `kimaki` signature (kimaki is a bridge that consumes opencode, but the session IDs we care about are kimaki's own).
• Any future runtime added to `runtimes/` gets the same one-liner.

If _register_cli_channel already runs at install time for each bridge, an adjacent _register_runtime_signature is the natural place to hang this — same lifecycle, same teardown.

Documentation

Add a short README section under "Outbound Dispatch" (or a new "Worktree session attribution" section) that documents:

• What signatures are registered and why.
• How DMC consumes them.
• That wp-coding-agents owns these brand names — if DMC ships kimaki/opencode-specific code, that's a layer violation and should be filed against DMC, not patched here.

Acceptance criteria

• kimaki and opencode runtime signatures registered via the chosen mechanism (filter, option, or both).
• Registration is idempotent (re-running install does not duplicate entries).
• Uninstall removes the registration (mirrors the existing channel-registration cleanup).
• README documents the integration model.
• No regression in the existing bridges/*.sh and runtimes/*.sh install/upgrade flows.
• No edits to CHANGELOG.md or VERSION — homeboy owns those.

Dependency note

This issue depends on Extra-Chill/data-machine-code#416 landing first. The filter `datamachine_code_worktree_runtime_signatures` (or whatever final name #416 lands with) must exist in DMC before wp-coding-agents has anything to register against. PRs can open in parallel — both reviewable independently — but wp-coding-agents won't be functional until DMC ships a release containing the filter.

Out of scope

• The generic-shape refactor of DMC's worktree-attribution code (tracked in DMC#416).
• Any unrelated wp-coding-agents work.