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 40 built-in language configs pass base schema
• Batch validation: 37 of 40 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.