DEN-3982 follow-up: advance reusable TJSV baseline and enforce option parity #80

Why

The merged Zed fleet scanner/reusable admission baseline is still ORESoftware/typespec-json-schema-validator@a4b731fbf82c4d162abd74fd03758fa32bb76176, while TJSV merged main has advanced to 4a5d049218adc2740d4cf78f612caf7f38f6f64c with later runtime-boundary, privacy, nested-namespace, and nested record/array drift coverage.

zed-pkg/zed-clients#69 also exposed a semantic configuration hazard: the reusable workflow explicitly uses seal_object_schemas: "false" so independently authored closure remains authoritative, while a specialized direct CLI consumer inherited the default true and stopped until its invocation was aligned.

Acceptance

• advance the reusable TJSV workflow pin and the fleet scanner minimum baseline together; never move one without the other;
• exact-head canaries for zed-interfaces, zed-clients, zed-pub-lib-core, zed-lib-core, and zed-orm-core must execute successfully before promotion;
• reusable and specialized/direct consumers must declare equivalent semantic options (int64_strategy, seal_object_schemas, polymorphic model strategy, probe/evidence policy) or carry an explicit reviewed exception;
• preserve human-authored TypeSpec and Draft 2020-12 JSON Schema as independent peer authorities; generated schemas and Contract IR remain evidence only;
• when closure is explicitly authored in both peers, emitter auto-sealing must not silently become a third policy source;
• retain current-input verification, refusal regressions, immutable SHA pins, and exact-head verification receipts;
• update the scanner exception ledger/minimum capability markers only after hosted execution is green;
• use zed-clients#69 PackageRef as the first required reusable-vs-specialized parity canary.

Parent: DEN-3982. Related: DEN-3828, DEN-3830, DEN-3600, #68, #76.

No credential changes, mutable pins, or authority rewrites.