Define resolved workflow specs for canonicalized recipe input paths

## Summary

WP Codebox currently treats recipe input mount paths as both caller-facing declarations and executable runtime paths. When recipe input mounts are canonicalized/materialized under `/tmp/wp-codebox-inputs/...`, workflow command args can still reach runtime execution with the original declared paths such as `/wp-codebox-vendor` or `/home/wpcom/public_html`.

The immediate symptom is #1696, but the architectural issue is broader: path canonicalization is a late helper rewrite rather than a single authoritative recipe execution boundary.

## Current path identities

- Declared recipe paths: caller-facing paths such as `/wp-codebox-vendor` and `/home/wpcom/public_html`.
- Canonical runtime paths: internal materialized paths such as `/tmp/wp-codebox-inputs/2-wp-codebox-vendor-...`.
- Command argument paths: values embedded in workflow args such as `cwd=`, `autoload-file=`, `tests-dir=`, `test-root=`, `phpunit-xml=`, etc.

These path identities can diverge. We have evidence that `recipeInputMountPathMap()` and `rewriteInputMountPathArgs()` produce the right canonical args, while `wordpress.phpunit` runtime execution still receives the original declared path.

## Desired model

Recipe execution should have a first-class resolved workflow spec phase:

1. Runtime setup prepares input mounts and returns a path resolution context.
2. Workflow steps are converted to resolved execution specs exactly once before `runtime.execute()`.
3. Runtime commands receive resolved runtime paths only.
4. Declared paths remain available as evidence/metadata, not executable args.
5. Diagnostics expose original args and resolved args.
6. If an executable arg still references a canonicalized declared mount target, recipe-run should fail loud before runtime execution.

## Acceptance criteria

- All recipe workflow command execution paths pass through one resolver before runtime execution.
- Nested workload/fuzz workflow execution uses the same resolver.
- `wordpress.phpunit` with input mounts for `/wp-codebox-vendor` and `/home/wpcom/public_html` receives canonical `/tmp/wp-codebox-inputs/...` args.
- Evidence records both original and resolved args for debugging.
- A guard catches unresolved canonicalized mount targets in executable args.
- Fix remains generic: no Homeboy or WPCOM-specific logic.

## Related

- Immediate bug: #1696
- WPCOM blocker run: `runner-exec-test-wpcom-homeboy-lab-e66e6a80-e042-4727-aa17-75b3a17ccf31`

## AI assistance

- **AI assistance:** Yes
- **Tool(s):** openai/gpt-5.5 via OpenCode
- **Used for:** Diagnosing the path model failure and drafting this architectural issue.

Trace recipeInputMountPathMap(), rewriteInputMountPathArgs(), and the workflow paths that call runtime.execute(); compare ordinary and nested workload/fuzz execution, including wordpress.phpunit. Define the resolved workflow-spec boundary so runtime commands receive canonical paths, while evidence keeps original and resolved args and recipe-run rejects unresolved mount targets.

Written by the indexing model from the issue text.