fix(ts): transfer generic JSDoc constructor fields across modules

Parent: #846. Related TypeScript compatibility: #548.

Reproduced on origin/main 2049105 with installed TypeScript 5.7.3 and the rebuilt Home home-tsc, under serial 3,840 MB memory guards. JavaScript owner:

/** @template T */
export class Box {
  /** @param {T} value */
  constructor(value) {
    /** @type {T} */
    this.value = value;
  }
}

TypeScript consumer:

import { Box } from "./owner.js";
const box = new Box("ready");
box.value = 1;
const bad: number = box.value;

With strict, noEmit, skipLibCheck, target es2020, module commonjs, allowJs and checkJs, TypeScript reports TS2322 at consumer (3,1) and (4,7), both with the expected string/number messages. Home instead reports TS2339 at (3,5) and (4,25): imported Box has no value member. A local same-file JS Box check and an equivalent TypeScript generic class imported across files both give the expected TS2322 pair in Home. Thus this is specifically loss of source-owned generic JSDoc constructor-member type during JS-to-TS Program transfer.

The current Program JSDoc type-expression subset cannot represent the class template parameter T; its class schema only transfers supported constructor fields. The #846 annotated concrete-field fix deliberately does not turn an unsupported generic member into any or silently accept the invalid writes. Acceptance: preserve the class template parameter in the source-owned schema, transfer the constructor assigned field with that parameter, instantiate it at the consumer, match both positive and negative TypeScript diagnostics, add Program and CLI regressions, and pass the relevant full guarded suites. No any fallback, diagnostic suppression, or fixture changes.

Resolved the constructor-assigned JSDoc generic field transfer in commits 2d58f3f and ed04a5c, both pushed to origin/main as glennmichael123 without coauthors. The second commit carries source-owned template constraints and defaults and preserves literal identity for constrained writes while widening cross-primitive diagnostic display as TypeScript does. TypeScript 5.7.3 and the freshly rebuilt Home home-tsc now produce matching codes, positions, and messages on the constrained and defaulted real-file controls. After rebasing on current main, guarded Program 421/421, CLI 84/84, and checker 4684/4684 passed; all heavy runs were serial under the 3,840 MB guard. A distinct non-generic direct class-field JSDoc annotation gap is tracked in #946, not hidden under this constructor-assigned issue.

Pushed 2d58f3f to origin/main as glennmichael123 without coauthors. The source-owned class schema now retains simple JSDoc @template names, resolves those parameters in constructor @param signatures and assigned-field @type annotations, and uses the same schema arity for imported class values. Verified against TypeScript 5.7.3 on three real-file controls: one unconstrained T with explicit @type {T} (two exact TS2322 diagnostics), one T with this.value = value inferred from @param {T} (two exact TS2322), and independent T/U on @template T, U (four exact TS2322, same positions/messages). Added Program serial/parallel regressions for both single-template field forms, a two-template Program regression, and a real CLI import-closure regression. Final guarded Program 418/418, CLI 82/82; checker target was a cache hit from the previously passing full run; fresh home-tsc build passed. Peak process-tree footprints: 2,358 MB, 2,236 MB, and 2,273 MB under the 3,840 MB cap. Remaining independently reproduced gap: @template {string} T owner with the same constructor field still yields two TS2339 in Home, whereas TypeScript reports TS2322 at consumer (3,1) with literal 1 vs ready, and TS2322 at (4,7) with string vs number. Constrained/defaulted JSDoc template semantics are not claimed or admitted by this slice. Keeping #945 open for those source-owned parameter constraints/defaults and their full positive/negative controls.