Support custom WordPress roots and full browser-action arguments on the native backend

[chubes4]

Follow-up to #2473 / #2475.

Problem

The wordpress-native backend runs stock WordPress from its pinned image and implements only part of the browser-action contract. Downstream consumers that supply their own WordPress distribution would silently execute against stock WordPress instead of their source, which produces misleading evidence.

Gaps

1. runtime.assets.wordpressDirectory is resolved by the CLI (packages/cli/src/commands/recipe-run.ts) and honored by Playground, but the native driver ignores it.
2. wordpress.browser-actions on native ignores route-host, auth-user-id, capture, step-timeout, and timeout.

Acceptance criteria

• A backend-neutral recipe supplying a custom WordPress root executes that source on the native backend, with provenance identifying the mounted source rather than the image default.
• Selecting native versus Playground requires no workflow command changes.
• route-host maps declared hosts to the contained runtime so host-dependent routing behaves as it does on Playground.
• auth-user-id authenticates as the requested fixture user; only runtime-generated fixture credentials are used.
• capture honors its declared streams, and unsupported tokens fail explicitly instead of being ignored.
• step-timeout and timeout bound individual steps and the whole action, and timeouts surface as typed, bounded failures with retained evidence.
• Unsupported arguments fail closed with actionable errors rather than silently degrading.
• Deterministic coverage plus a containment-gated live test proving a custom WordPress root and the full argument set.

Non-goals

• Consumer-specific paths, fixtures, or product names in runtime-core or the native package.

AI assistance

AI assistance: OpenCode with openai/gpt-5.6-sol was used to verify the gaps in the CLI and native driver and draft this issue. Chris reviewed and owns the report.