Related: #846.
Pinned TypeScript 5.7.3 oracle with an admitted checked-JavaScript owner: owner.js exports a JSDoc ReadonlyArray<number> and a mutable Array<number>; main.ts reads both, writes indices, calls push, and makes deliberately wrong assignments. Under both checkJs=true and checkJs=false, tsc reports five diagnostics in source order: TS2542 at main.ts(4,1), TS2339 at (5,16) for readonlyValues.push, TS2322 at (6,7), TS2322 at (7,1), and TS2345 at (8,13). Home reports the other four exactly but silently accepts readonlyValues.push. A local TypeScript-only control using const readonlyValues: readonly number[] likewise reports TS2339 in tsc and no error in Home, so the defect is in the general checker rather than import projection.
Code evidence: packages/ts_checker/src/check.zig lookupArrayLikePrototypeMember, arrayLikePrototypeMember, direct member-access and call-signature paths all consult lib.arrayProto regardless of typeIsReadonlyArrayLike; packages/ts_checker/src/lib.zig arrayProto includes push/pop/sort/splice and other mutators. The declared-array fallback also searches both Array and ReadonlyArray aliases without receiver mutability. A proper fix needs a readonly array member surface and consistent selection across property access, call signatures, indexed/keyof lookup and declaration/augmentation paths. Preserve genuine ReadonlyArray interface augmentations, readonly callback parameter types, and mutable Array behavior; do not suppress TS2339 by name or weaken the oracle. Keep this issue open until exact CLI, local checker, and relevant regression suites pass under the agreed memory guard.