fix(cli): run regexp-selected scripts concurrently in recursive runs (#14999)

A task the recursive runner dispatches holds every script a RegExp selector
matched in that package, and it ran them in sequence. `RunArgs::run` has started
them together since it gained `run_selected_scripts`, and pnpm 11 fans them out
through its `limitRun` limiter, so the recursive Rust path was the odd one out.

`run_project` now picks between a concurrent and a sequential mode the way the
single-project path does, sharing the verdict bookkeeping through
`ScriptRunState` so both record the same transitions.

Running several scripts per task breaks the equivalence the scheduler relied on:
capping dispatched tasks caps running scripts only while a task runs one script
at a time. `ScriptBudget` restores it. It is one counting semaphore for the whole
run, sized by `script_concurrency` over every matched script, and each script
holds a permit while it runs. A permit is never held while waiting for another,
so the budget cannot deadlock, and single-script tasks are unaffected: the outer
task cap and the budget are then the same number and no script ever waits.

Two consequences of the concurrency needed handling:

- A task's own failure outranks the cancellation it causes. Under `--bail` the
  failing script cancels the run, its sibling is killed, and the sibling's
  cancellation used to overwrite the task's verdict, because `RunOutcome::record`
  reads `cancelled` before `failed`. The run then reported
  ERR_PNPM_RECURSIVE_FAIL instead of naming the project with
  ERR_PNPM_RECURSIVE_RUN_FIRST_FAIL, unlike a failure in another package.
  `ScriptRunState::cancelled_script` keeps the failure.
- A script must not start on a permit it won after the run was cancelled.
  `run_stages` returns early on `SlotOutcome::Ungated` without consulting the
  tracker, so such a script reached `run_script` and spawned a process that
  registration then killed. `start_script` returns no permit in that case, which
  is the guard `runRecursive.ts` applies after its own limiter on pnpm 11.

Closes pnpm/pnpm#14933

---------

Co-authored-by: Zoltan Kochan <z@kochan.io>
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>