feat(ts): opt-in `sound` mode that closes TypeScript's known unsoundness holes

Problem

Home's checker faithfully reproduces tsc's unsoundness: method parameters are always bivariant (which also makes mutable arrays covariant), a readonly source may flow into a mutable target ("still allowed for now"), and as only errors when the types are not comparable at all. Nothing checks non-null !, explicit any, lying type predicates or @ts-ignore. This is the core of "sound types in the engine": an opt-in mode where a program that type-checks cannot have these type errors at runtime. (New design direction.)

Evidence (origin/main @ d4b219507)

• packages/ts_checker/src/relation.zig:2903-2912
• packages/ts_checker/src/check.zig:195420

Scope

• Under home.sound (see the HM infra issue), add one rule per hole:
  • strict (contravariant) method parameter variance; mutable arrays/containers invariant
  • readonly → mutable assignment rejected
  • as downcasts require a runtime check (or are rejected); ! requires proof or a check
  • explicit any banned (use unknown); @ts-ignore / @ts-expect-error banned
  • user-defined x is T predicates must be verified or generated (see the validate<T> issue)
  • noUncheckedIndexedAccess and exactOptionalPropertyTypes forced on
• Write a short spec in docs/ listing each hole, the rule, and the escape hatch.

Acceptance criteria

• One fixture per hole, each producing exactly one HM diagnostic in sound mode and none in default mode.
• TS conformance unchanged with sound mode off.
• Report: how many diagnostics sound mode produces on a real project (e.g. the pinned Zod bench).

Links

Depends on: #782, #783 Part of #814.