fix: evaluate property default initializers via AST instead of vm2

[yehia2amer]

Please:

• Make your pull request atomic, fixing one issue at a time unless there are many relevant issues that cannot be decoupled.
• Provide a test case & update the documentation in the Readme.md

---

This drops the vm2 dependency entirely.

Why

Every scanner I point at a project that pulls this package in lights up because of vm2 — Dependabot, npm audit, our internal SCA, all of them. vm2 is archived/unmaintained and the sandbox-escape advisory in #631 (GHSA-99p7-6v5w-7xg8) has no fix coming, because the maintainers concluded it's not really fixable. #635 bumped the version to quiet it down, but a version bump can't fix something that has no patched release, so it keeps coming back.

Digging into why vm2 is even here: it's only used in one spot — evaluating a property's initializer to figure out the default value:

class Foo {
  bar: string = "baz";  // <- we want "baz" in the schema default
}

The history is kind of a loop, actually. #628 flagged that running the tool on a malicious .ts file could execute code (because it evals the initializer text), so #629 swapped vm → vm2 to sandbox it harder... and then #631 pointed out vm2 itself is the vulnerable thing now. So we went from "eval is scary" to "the thing we used to make eval less scary is scary." 🙃

The fix / why this way

Instead of executing the initializer in any sandbox, just read the literal value straight off the TypeScript AST (ts.isStringLiteralLike, ts.isNumericLiteral, ts.isArrayLiteralExpression, etc). We already have the parsed node — there's no real reason to run it through a VM to find out that [1, 2, 3] is [1, 2, 3].

Nice side effect: this closes #628 too. Since nothing is ever executed, a malicious initializer like bar = (() => { /* do evil */ })() just isn't a supported literal node, so it returns undefined and hits the existing "unknown initializer" warning path — same as before, minus the arbitrary code execution.

I deliberately kept it to the raw AST layer and did not reach for the TypeChecker. The TypeChecker would happily resolve bar = SOME_CONST to its value by following references across files — which sounds nice but is exactly the "reach beyond what's literally written here" behavior that made this risky in the first place, and it also can't give you array literals as values (they widen to {}). vm2 didn't resolve those references either, so staying at the AST layer keeps behavior identical for valid defaults.

Supported literal forms: string, number (including negatives), boolean, null, and arrays of those — which matches what the old vm2 block accepted.

Testing

Added a default-properties-initializer fixture covering the above, including a single-quoted string and a negative number (a couple of cases a naive JSON.parse swap would've choked on, which is partly why I went the AST route). All existing tests still pass — default-properties / annotation-default are unchanged, so behaviour for real defaults is the same.

api.md picked up the new fixture automatically via yarn docs.

Happy to adjust naming or split things out if you'd prefer — first PR here so lmk if I got the conventions wrong.

Closes #631
Closes #628