Declare isolated workers in bounded recipe integration

## Problem

`tests/bounded-recipe-plan.integration.test.ts` requests bounded-plan concurrency 2 but creates a WordPress Playground runtime without a worker count. Since #2323, mutable Playground runtimes intentionally default to one request worker. Both concurrent `wordpress.run-php` entries therefore occupy a one-worker transport and time out after 30 seconds.

This remained hidden because #2459 corrected only the fake-runtime unit concurrency proof. The real recipe integration still omitted the runtime capability it exercises. It failed both in the full aggregate and standalone while verifying #2464.

## Desired outcome

Make the integration fixture explicitly request two Playground workers, matching its plan concurrency and per-entry process identities. Preserve the production default of one worker for mutable-state coherence.

## Acceptance criteria

- The real bounded recipe integration executes both entries successfully.
- The fixture explicitly declares the worker concurrency it requires.
- Production runtime defaults remain unchanged.
- The full smoke aggregate passes.

## AI assistance

GPT-5.6 Sol via OpenCode traced the integration timeout through the bounded scheduler and Playground request-worker configuration and drafted this tracker under Chris Huber's direction.

Start with tests/bounded-recipe-plan.integration.test.ts and inspect how the WordPress Playground runtime is created for the bounded-plan concurrency-2 case. Run that standalone integration test first, then the full smoke aggregate. Done means both wordpress.run-php entries complete successfully, the fixture declares two workers, and production defaults remain unchanged.

Written by the indexing model from the issue text.