test(ts/cli): anchor the stderr warning filter on Node's own prefix

[AndreasKoestler]

Refs #12. Rebased onto current main and cut down to the one item that is still real.

packages/cli/tests/run.test.ts asserts filterWarnings(r.stderr) is '', filtering out Node's one-time ExperimentalWarning: globSync notice. The filter matched ExperimentalWarning and --trace-warnings as unanchored substrings, so any line the CLI itself emitted containing either literal — a step name, a diagnostic, a hint — was silently dropped from the assertion instead of failing it.

Now anchored on the prefixes of Node's own two-line notice:

(node:12345) ExperimentalWarning: globSync is an experimental feature ...
(Use `node --trace-warnings ...` to show where the warning was created)

• /^\(node:\d+\) ExperimentalWarning:/
• /^\(Use \node --trace-warnings/`

Verification

The suite being green does not verify the patterns here: on Node v22.22.2 the CLI emits nothing on stderr at all (globSync is no longer experimental), so the filter is inert and both the old and new versions pass trivially. I checked the patterns against the notice format directly instead — both notice lines are filtered, and CLI-style lines containing the same literals are kept:

filtered (want both true) : [ true, true ]
kept     (want both false): [ false, false ]

Worth noting on the back of that: the filter may be dead weight on current Node. Happy to delete it instead if you'd rather — but that's your call on the supported Node range, so this PR just makes it correct.

pnpm check and pnpm build green; release/lint-commits.sh OK.

Dropped from the original PR

The second item — documenting that external consumers need @varar/core resolvable from the package holding their oaths — no longer applies, so I removed it rather than rebasing it:

• The generated virtual module now imports only @varar/vitest/runtime, and plugin.ts:123-128 says explicitly that this is so importing @varar/core "would fail under pnpm's strict node_modules layout". That path is already fixed in the plugin.
• resolve.dedupe still lists @varar/core, but the module-level mutable state (stepEntries, customTypes) lives in packages/varar/src/internal.ts, and @varar/varar is a direct consumer dependency, so it dedupes fine. @varar/core has no module-level mutable state, so a split instance is harmless.

Documenting a requirement that isn't one seemed worse than dropping it.

The third item from #12 (the registry.ts non-null assertion) was already resolved. Left #12 open rather than auto-closing it, since only part of it is mine to close.

[aslakhellesoy]

Please remove the unrelated Rust code from this PR. And/or merge main into this PR.

[AndreasKoestler]

Sorry about the Rust noise here — I'd branched this off a fork main that already had the Rust port merged into it, which is why it showed up in this PR and the other two. That's moot now that #21 landed.

I've force-pushed this branch: rebased onto current main (so the varar rename and the packages/cli layout), and cut it to a single commit touching one file. Title and description updated. The docs half of the original PR is gone — the plugin already fixes what it described; details in the description.