refactor(content-lane): inject registry validators via RegistryLaneSpec instead of hardcoded imports

[JSONbored]

Context

Follow-up to #2433 (naming/export cleanup), part of the same chain making the content-lane registry-review engine reusable by any self-hosted maintainer's own registry repo — tracked under the parent roadmap.

The content-lane orchestrator (src/review/content-lane/orchestrator.ts) is otherwise fully generic: it takes a RegistryLaneSpec and never hard-codes a file path, a repo name, or a domain assumption. But its per-entry semantic validation step is not — runSurfaceReview imports two specific validator functions directly and calls them unconditionally. Those validator functions correctly encode one registry's own domain rules (that's expected and fine — a different registry's entries mean different things and need their own domain-specific checks), but the orchestrator having a hard-coded import of them means a second registry can't supply its own validation logic without editing the shared orchestrator file itself.

Requirements

• Extend the RegistryLaneSpec interface with two optional function-reference fields that let a spec supply its own per-entry and per-provider validators.
• runSurfaceReview calls the spec-supplied validators instead of importing any specific validator module directly — the orchestrator becomes fully validator-agnostic.
• Our own registry's spec object continues to supply its existing validators via those new fields — zero behavior change for any currently-configured repo.
• When a spec has no validator configured, the orchestrator returns a clear "manual review — no validator configured for this registry" result rather than throwing or silently merging. This is the correct degraded mode for a brand-new registry that hasn't written domain-specific validation yet (structural checks — file scope, entry-count cap, duplicate detection — still apply).
• Document on the new interface fields that they're code-supplied for now; a later issue in this chain adds a config-driven selection mechanism on top (so a maintainer can pick a registered validator by name from .gittensory.yml without writing TypeScript, if a suitable one already exists) — this issue only needs to make the injection point clean, not build that selection mechanism.
• Update the orchestrator's module-level doc comment, which currently names the removed direct-import validators by name in prose.

Deliverables

• RegistryLaneSpec gains the two validator-callback fields (documented, with a clear default-degraded-mode explanation).
• orchestrator.ts no longer imports any registry-specific validator module directly.
• Our own spec's construction updated to pass its existing validators through the new fields — behavior-preserving.
• Test specs used purely to exercise the structural layer (scope classification, entry-count cap, duplicate detection) are unaffected; test specs that exercise the full assessment path are updated to supply validators.
• Full unsharded coverage + npm run test:ci green — the existing end-to-end regression suite (including the real-fixture regression test for the original multi-entry-cap bug fix) must pass with an unchanged outcome.

Expected outcome

A second self-hosted maintainer who wants deterministic, AI-free structured-data review for their own registry can write one new validator module (following the existing one as a template) and register it on their own spec object — with zero changes to the shared orchestrator. This is the concrete unlock that makes the orchestrator genuinely registry-agnostic, not just file-pattern-agnostic.

[linear-code]

JSO-2456