feat: add object-form table factory API

[tecfu]

Add Table.create({ header, rows, footer, options }) as a clearer extension point while preserving every existing positional overload. This gives future API additions a named home without breaking compatibility.

[tecfu]

Review: merge (one note)

Table.create dispatches onto the exact positional shapes the existing factory accepts — same Factory entry point, no duplicated parsing — and every positional overload is untouched. Verified: Table.create({header, rows, options}) matches positional Table(header, rows, options) output byte-for-byte; the footer and rows-only branches hit Factory the same way; matrix 0; 111/111 vitest; 21/21 goldens; typecheck/lint clean.

Two details that I checked because they'd be the obvious bugs:

• create({ rows }) with no header: header.length is 0 so it takes the 2-arg path (Factory([rows, options])), matching positional. ✅
• The options parameter for the 3/4-arg positional paths is in the right slot for each branch. ✅

1 note: the test uses expect(table.render()).toContain("Ada") — weak: any output containing "Ada" passes (even a header-dropped or row-shifted bug would), and it doesn't assert that the options were honored. Since this is the only coverage of a new public entry point, worth strengthening to (a) byte-equality with the positional equivalent, and (b) something that proves options reached the renderer (e.g. an assert that the 30-wide option constrains the line width).

Sincerely qwen3.8-flash-next

[tecfu]

Review: merge, with test/documentation note

The implementation is clean and preserves the existing positional factory paths by dispatching directly to the same Factory entry point. The three dispatch cases are correctly shaped.

One thing I would still tighten before merge: the only new behavioral test asserts merely that the rendered output contains Ada. That does not prove the object-form API selected the same overload or that options were actually applied. Please make this a parity test against the equivalent positional call, ideally byte-for-byte, and assert one observable option effect such as width. Since Table.create is a new public API, a short README/type-level usage example would also be appropriate.

No architectural blocker found.

— GPT-5.6 Luna

[tecfu]

Re-review: test parity fixed

The object-form factory test now compares complete rendered output against the equivalent positional factory call, verifying dispatch and option propagation.

CI is running on the updated test. No implementation blocker found.

— GPT-5.6 Luna

[tecfu]

Review pass 2

Checked the dispatch against every positional shape: header-only, rows-only, and footer cases all render byte-identical to Table(header, rows[, footer][, options]), and a non-array rows (the automattic object-row style) still routes through Factory correctly. The parity test now compares full output, closing the earlier weak-assertion note.

One remaining gap: Table.create is a new public entry point and neither the README nor the types carry a usage example for the object form - the PR itself is the only documentation. Worth a short README snippet.

Also note #135 and #130 both append to test/core.test.ts and conflict regardless of order; whichever lands second needs a trivial rebase.

No blocker. Mergeable.

Sincerely deepseek/deepseek-v4.1-flash