perf: only scan the run store when pruning dev-runtime snapshots

[ryanda9910]

Addresses the boot-time half of #474.

The problem

pruneDevelopmentRuntimeArtifactsSnapshots protects snapshots that a still-running turn depends on. To find them it walks all of .workflow-data and readFiles every file under 1MB:

const source = await readFile(path, 'utf8');
if (!shouldScanWorkflowDataSource(source)) return;   // ← the filter runs *after* the read

So boot cost scales with everything the local workflow world has ever written, not with live work. The store in #474 had reached ~10,900 files, and a full read of it ran on every eve dev boot (and on every authored-source change, via dev-authored-source-watcher).

The fix

A snapshot reference only reaches disk through a run — input.serializedContext["eve.bundle"]. The other stores of @workflow/world-local (events, steps, hooks, streams, waits, .locks) never carry one, and they are almost the entire store: the reported breakdown was 8,466 events / 1,460 steps / 459 hooks against 500 runs — runs are ~5% of the files.

Those directories are now skipped by name, before any read happens. Runs are still scanned exactly as before, so nothing a live run depends on loses its protection.

Measured

Rebuilt a store at the reported proportions (10,885 files) and ran the collector both ways:

	files read	time
before	10,885	~253 ms
after	500	~12 ms

500 reads = exactly the run count, i.e. every run is still visited.

Test

Added an integration test that pins both halves:

• a snapshot referenced by a non-terminal run survives the prune (no regression in protection)
• a snapshot path planted in the event store does not survive — which is what proves the directory is actually skipped

Verified by mutation: removing the skip makes exactly that new test fail, and the 13 pre-existing tests pass either way.

pnpm vitest run --config vitest.integration.config.ts src/internal/nitro/dev-runtime-artifacts.integration.test.ts → 14 passed. oxlint and tsc clean. Patch changeset included.

Not covered here

#474 also reports per-operation directory scans inside @workflow/core's local queue, and runs stranded in running forever by killed dev servers. Both live outside this file — happy to take either as a follow-up if you'd like them split that way.

[vercel]

@ryanda9910 is attempting to deploy a commit to the Vercel Team on Vercel.

A member of the Team first needs to authorize it.