record captures 0 samples when started inside a scenario run

## Symptom
Starting a recording **inside a `scenario` run** captures **0 samples**, even though the recorder reports `recording:true` and runs for the full duration.

Repro (live SE, player loaded):
```
scenario run: [
{tool: record, args:{action:start}},
{wait: 2000},
{tool: record, args:{action:status}}, // -> sampleCount: 0
{tool: record, args:{action:stop}} // -> sampleCount: 0, recordedMs: 2005
]
```
The **same** start → wait → status → stop issued as **separate** top-level tool calls captures normally (350 samples in 2s, 1309 in 35s). The one-time manifest/anchor (also a `MainThread::RunAndWait`) is captured fine; only the per-tick sampler loop gets nothing.

## Hypothesis
The sampler thread grabs each pose via `MainThread::RunAndWait(&ReadPose, 2000ms)` (queued on the main thread via SKSE TaskInterface). A blocking `scenario` `run` appears to starve that main-thread task processing for its whole duration: `recordedMs` ≈ the scenario's wall time and every tick yields nothing, consistent with each `RunAndWait` timing out (or the ReadPose tasks never being pumped) until the scenario returns. Console/pose steps *within* a scenario do reach the main thread, so the interaction is specific to the concurrently-running sampler.

## Scope / impact
Pre-existing (recorder + scenario both predate the v2/menu work); reproduced on an integration build of #58+#59+#60 but **not** caused by any of them (the `RunAndWait` slicing in #60 behaves identically in this path). Matters for a benchmark harness that scripts `record start` inside a `scenario`. Workaround: drive record start/stop as separate top-level calls, not scenario steps.

Found during integration QA of the open recording PRs.