test: add schema validation tests for language and framework configs

[yiziff]

Add comprehensive test coverage for:

• TreeSitterConfigSchema, FilePatternConfigSchema, LanguageConfigSchema
• StrictLanguageConfigSchema refinement (requires extension or filename)
• FrameworkConfigSchema validation (min(1) constraints, optional fields)
• Batch validation: all 41 built-in language configs pass base schema
• Batch validation: 38 of 41 pass strict schema (3 content-detected configs intentionally excluded: kubernetes, github-actions, json-schema)
• Batch validation: all 10 built-in framework configs pass schema
• Integrity checks: unique IDs, non-empty concepts, no duplicate extensions, framework languages reference valid language IDs
• Framework layerHints key-value validity

Summary

Linked issue(s)

How I tested this

• pnpm lint
• pnpm --filter @understand-anything/core test
• pnpm test
• Manual smoke test (describe above)

Versioning

• Version bumped in all five manifests, OR
• N/A — internal/docs-only change

[tirth8205]

Checked out in an isolated worktree, installed deps, built (tsc clean), and ran the suite: all 51 new tests pass, and the full core suite stays green (790 tests / 36 files).

The tests are mostly substantive rather than tautological. I verified the load-bearing claims against the actual configs:

• There are exactly 41 language configs and 10 framework configs (matches the toHaveLength assertions).
• The three content-detected configs that lack both extensions and filenames are exactly {github-actions, kubernetes, json-schema} — matching CONTENT_DETECTED_IDS.
• No duplicate extensions across configs, and every framework's languages array resolves to a real language id (e.g. spring -> ['java','kotlin']).

Strongest coverage: the base/strict batch trio (base passes all / content-detected fail strict / non-content-detected pass strict) genuinely locks the intended base-vs-strict distinction, and the framework→language referential-integrity check would catch a typo'd language id. Good additions.

Minor points (non-blocking):

• The StrictLanguageConfigSchema refinement block (including the "at least one extension or filename" message assertion) duplicates coverage already present in language-registry.test.ts (its own StrictLanguageConfigSchema refinement describe). Not harmful, just not net-new.
• every config has a non-empty id/displayName are largely redundant with the base-schema batch safeParse (the schema already enforces .min(1)).
• The hardcoded counts (41 / 10) are deliberate snapshot tripwires — fine — but the PR description is already stale: it says "40 built-in language configs" and "37 of 40", while the code/tests use 41 (and 38 of 41 pass strict). Worth fixing the description text for accuracy.

Net: solid, accurate test-only PR with real invariant coverage. Recommend addressing only the stale description numbers; the duplication is optional cleanup.

[yiziff]

Thanks for the thorough review and testing, @tirth8205 5! You are totally right about the counts — the recent addition of the Dart language config bumped the total. I've updated the PR description text to reflect the accurate numbers (41 and 38). Let me know if we are good to go！ 谢谢！