Downloaded page/test templates pass constructor argument tuples as one argument

On main a72b99f60680ffbe56a4c72e113ca52c9469921e, the generic Download page.tsx and Download test.ts templates serialize the result of getConstructorParams() and pass the entire result as one constructor argument:

const input = [{ limit: 7 }, 3]
const solver = new ProbeSolver(input as any)

For a solver whose original arguments were { limit: 7 }, 3, reconstruction receives [[{ limit: 7 }, 3]] as its argument list instead. The second argument becomes undefined and even a one-element tuple is nested incorrectly.

This is not only a hypothetical tuple convention: the README returns [{ start: this.value, target: this.target }], site/ExamplePipelineSolver.ts returns tuples, and the breadcrumb demo returns [this.params]. The generic templates in lib/react/DownloadDropdown.tsx do not unpack them.

Minimal solver for manual reproduction

class ProbeSolver extends BaseSolver {
  input: { limit: number }
  scale: number
  constructor(input: { limit: number }, scale: number) {
    super()
    this.input = input
    this.scale = scale
  }
  override getConstructorParams() { return [this.input, this.scale] }
  override _step() { this.solved = true }
}

Pass new ProbeSolver({ limit: 7 }, 3) to the downloader and export either generic source template. After resolving the generated project's imports, its construction should restore input.limit === 7 and scale === 3; the current construction gives the tuple to input and leaves scale undefined.

Executed verification

I executed the actual unmodified DownloadDropdown handlers/templates from Git blob e5d0a6a96c71abaccc43ef7820ddaad95e77bb2b, captured their generated Blob text, transpiled it with TypeScript 5.8.3, and executed the generated constructor calls with a probe subclass of the actual BaseSolver. The source blobs were SHA-checked.

Results for both page and test templates:

Eight tuple cases fail the reconstruction contract; two legacy-object controls pass. Node 22.16.0 was used. React hooks, DOM download plumbing and the generated test's snapshot host were mocked solely to invoke/capture the handlers; this is not a browser-click test or a full generated-project build. The real handler/template strings and constructor invocations were executed without changing their argument logic.

A fix should align generated construction with the tuple convention while deliberately deciding how to preserve legacy plain-object returns. The SchematicTracePipelineSolver-specific page template was not covered by this reproduction. Separate Date-cleanup PR #38 does not change the templates and does not resolve this issue. Prepared with ChatGPT assistance and the account owner's authorization.

Start in lib/react/DownloadDropdown.tsx and inspect the generic Download page.tsx and Download test.ts templates, focusing on how getConstructorParams() is passed to the generated constructor. Reproduce with the ProbeSolver example or the issue's verification cases; done means tuple arguments are restored correctly in both templates, with legacy plain-object behavior deliberately preserved or documented.