Support typed plugin dependency overlays for sibling contract smokes

[chubes4]

Problem

WP Codebox can already mount raw runtime stack files and prepare the special php-ai-client runtime overlay, but product smokes still need a clean way to prove a consumer plugin against sibling dependency worktrees.

The immediate case is Static Site Importer. SSI depends on Composer-installed sibling packages like chubes4/block-artifact-compiler and chubes4/block-format-bridge, with BFB carrying a prefixed html-to-blocks-converter bundle. Current verification can only approximate this by hardcoding mounts into the consumer plugin's vendor/ layout, which makes the smoke know SSI's Composer internals and weakens provenance.

That is verification infrastructure. It should live in WP Codebox, not as visual repair synthesis or dependency shims inside Static Site Importer.

Desired capability

Add a typed recipe contract for plugin dependency overlays that lets a recipe say: mount this local Composer/package dependency worktree into this mounted consumer plugin before setup, activation, and workflow steps.

Possible shape:

{
  "inputs": {
    "extra_plugins": [
      {
        "source": "/Users/chubes/Developer/static-site-importer",
        "slug": "static-site-importer",
        "pluginFile": "static-site-importer/static-site-importer.php"
      }
    ],
    "dependency_overlays": [
      {
        "kind": "composer-package",
        "package": "chubes4/block-artifact-compiler",
        "source": "/Users/chubes/Developer/block-artifact-compiler@branch",
        "consumer": "static-site-importer"
      },
      {
        "kind": "composer-package",
        "package": "chubes4/block-format-bridge",
        "source": "/Users/chubes/Developer/block-format-bridge@branch",
        "consumer": "static-site-importer"
      }
    ]
  }
}

The exact field names can differ, but the contract should keep caller intent typed and provenance-rich instead of requiring raw vendor/chubes4/... mount paths.

Acceptance criteria

• Add a recipe-level plugin dependency overlay contract separate from raw inputs.mounts, runtime.stack.mounts, and runtime.overlays.
• Support an initial composer-package overlay kind that maps package names to the mounted consumer plugin's Composer vendor path.
• Mount dependency overlays after consumer plugins are mounted and before activation, plugin runtime setup, probes, fixture imports, site seeds, and workflow steps.
• Validate sources, consumer plugin references, package names, and computed target paths before runtime work begins.
• Record provenance in metadata/artifacts: package name, source path/ref, consumer plugin, target path, digest, and user metadata.
• Fail clearly when the dependency source is missing, the consumer plugin is not present, or the package name cannot be mapped safely.
• Add focused smoke coverage proving a mounted plugin can read a dependency overlay from a sibling package source without hardcoding raw mounts in the recipe.
• Keep product-specific repair/synthesis logic out of WP Codebox; this is generic verification infrastructure.

Related context

• Runtime stack mounts landed in Support recipe runtime stack mounts #404.
• Prepared runtime overlays landed in Support prepared runtime overlays #407, but currently cover only the php-ai-client bundled-library path.
• Playground backend overrides landed in Support recipe Playground backend package overrides #631.
• Codex runtime overlay profiles landed in Add Codex subscription runtime overlay profile #745.

AI assistance

• AI assistance: Yes
• Tool(s): OpenCode (GPT-5.5)
• Used for: Drafted this issue from investigation of WP Codebox runtime overlay support and Static Site Importer sibling dependency smoke needs. Chris remains responsible for review and prioritization.