fix(ci): drop in-file test concurrency, keep file-level parallelism

The fourth CI run failed broadly: ~15 timing-sensitive tests (throttle, flush,
resize clear-counts, rapid-input ordering) failed under sequence.concurrent on
the 4-core ubuntu runner. These assert render/commit counts driven by the
~32ms commit throttle; in-file concurrency starves them of wall-clock when many
share few cores. It passed locally only because dev machines have more cores —
the classic "works on my 12-core mac" trap.

Remove sequence.concurrent from both the main and PTY configs; keep
fileParallelism (pool: forks), which is the proven, stable win (PTY suite still
~3x faster than serial). The it.sequential/describe.sequential markers and
context-local expect become harmless no-ops under serial in-file execution.

Verified cold (no dist): vp run ci exits 0, 0 lint warnings, all tests pass.

packages/runtime-tests/vitest.pty.config.ts

@@ -12,12 +12,13 @@ export default defineConfig({
     // wall-clock bottleneck). testTimeout stays generous (15s vs ~2s slowest
     // test) to absorb CPU contention on smaller CI runners.
     pool: "forks",
+    // Files parallelize across forked workers (~3x faster than serial — the PTY
+    // suite is the CI bottleneck). Tests within a file run SERIALLY: many of
+    // these assert timing-sensitive render/commit counts driven by the ~32ms
+    // commit throttle, and in-file concurrency starves them of wall-clock on a
+    // 4-core CI runner (it passes on higher-core dev machines, which is the
+    // trap). File-level parallelism is the proven, stable win.
     fileParallelism: true,
-    // Tests run concurrently by default. Each spawns its own isolated PTY
-    // subprocess (or in-process app) with no shared state, and rendering is no
-    // longer wall-clock-dependent (resize renders synchronously), so exact
-    // render-count assertions stay deterministic even under CPU contention.
-    sequence: { concurrent: true },
     testTimeout: 15000,
     env: { FORCE_COLOR: "3" },
   },