feat(entrypoints): stage-0 framework gate and the unresolved counter

[rahlk]

Closes #155. Unit 2 of the entrypoint spec (#150); plan docs/design/plans/2026-09-03-entrypoints-units-2-5.md, Task 1.

Unit 1 (#154) landed the contract with an honest-but-empty report. This makes it honest: which frameworks the project actually uses, and which decorator/base spellings nothing could name.

What this adds

• src/entrypoints/ — the pass moves out of src/schema/ into its own package (detect.ts, pipeline.ts, rules.ts types only, index.ts), mirroring python's codeanalyzer/entrypoints/
• Stage-0 framework gate — a framework is present if first-party source imports it OR the dependency manifest names it (an import may be dynamic); both sides lowercased. report.frameworks_detected is now populated.
• The unresolved counter — every decorator and base-class spelling that neither the import table nor the module itself can name, excluding JS globals, declared types, module-level declared names, and imported heads. This is what lets a consumer tell "no entrypoints" from "entrypoints the analyzer could not name".

No rules and no matcher yet: the gate has nothing to gate except the report. Those are unit 3, stacked on this branch.

Verification

• bun test — 252 pass, 0 fail (5 new); the unit-1 contract test passes unchanged
• Task-scoped review clean: spec compliant, approved
• One deviation from the plan's literal code, root-caused rather than papered over: declare const Mystery lives in mod.fields, not mod.types, so knownHeads reads both — otherwise a declared name leaked into the counter

Deferred (minor, for the unit-5 whole-branch review)

• Reset and count run as two passes over the symbol table; foldable into one
• isSignature classifies a lowercase-headed dotted spelling as an in-project signature, so an unresolved ns.Thing escapes the counter — later units must not assume the classifier is airtight