test: prove sibling flow creation through REST

[chubes4]

Summary

• add executable WordPress REST coverage proving two independent flow creations return distinct IDs and remain persisted as siblings
• strengthen the Pipeline Builder runtime fixture to require two successful POST responses, no flow_creation_failed, distinct IDs, and exactly two cards after reload
• reclassify the stale known-defect replay as regression coverage

Determination

The original production failure was repaired by the shared SQLite savepoint portability fix in #3346 (a2844a5f). Flow creation already delegates through POST /datamachine/v1/flows to datamachine/create-flow, and no production compensation is needed.

The new managed WordPress test executes that real REST path on current main: two POSTs return HTTP 200, produce distinct flow IDs without flow_creation_failed, and a subsequent REST GET returns both siblings. Production PHP LOC change: 0. Test/fixture impact: +37/-3.

Verification

• managed FlowsEndpointTest: 10 passed, 0 failed, 0 skipped
• managed FlowCreationAtomicityTest|TransactionScopeTest: 18 passed, 0 failed, 0 skipped
• changed-scope lint: zero findings
• changed-scope architecture audit: zero introduced findings
• Pipeline Builder fixture contract: passed
• transaction scope smoke: 0 failures
• frontend build: passed

The bounded seven-case runtime-backed browser suite was attempted but blocked before WordPress boot because WP Codebox resolved the nested fixture's ../.. runtime requirement against the worktree root, yielding nonexistent /mnt/extrachill-workspace/data-machine.php. Tracked upstream as Automattic/wp-codebox#2385. No runtime product claim is based on that blocked run; the executable managed REST proof is the closure evidence.

Fixes #3254.

AI Assistance

OpenAI GPT-5.6 Sol via OpenCode traced the current path, added the focused regression coverage, ran verification, and documented the WP Codebox infrastructure blocker. Chris Huber remains responsible for every line.