Hold the public surface to a report, and the report to the Rust

[tamnd]

Two links of one chain, in the package job because it already pays for the build they need.

The first asks whether binding.d.cts still says what the Rust says. That file is generated by the build and committed, and a committed generated file is one that can go stale: change a signature, forget to rebuild, and the package ships types describing a function that is no longer there. Nothing was checking that until now.

The second asks whether etc/zudb.api.md still says what binding.d.cts says. The report is what api-extractor is for here: a change to what this package exports arrives as a diff in one small file somebody has to read, rather than as a line buried in six hundred generated ones. The report is committed, npm run check:api verifies it, and npm run check:api:update is what you run when the change was intended.

What the report leaves out is written into the workflow beside it rather than left to be discovered. api-extractor reads declarations rather than the type checker's merged view, so it does not follow the declare module augmentation in zudb.d.cts, and stream and Symbol.asyncDispose are missing from Connection in the report. Those two are held from the other side, by the fixtures under test/types that call both and are compiled by check:types under the settings a user's compiler would use.

Both gates are validated the way the leak gates in the last change were: a renamed export has to fail them, and the step that renames one puts the tree back before anything else looks at it.

projectFolder is spelled out in api-extractor.json because there is no tsconfig.json at the root to infer it from, and tools/api-extractor.tsconfig.json is the settings from test/types with skipLibCheck turned on, since this run is a reader rather than a checker.