feat: accept unit-literal array defaults in string syntax

[yamcodes]

Resolves #1661

Summary

Allow a unit-literal array after = in string syntax, with either quote style:

type({ HOSTS: "string[] = ['localhost']" })
type({ HOSTS: 'string[] = ["localhost"]' })
type({ ports: "number[] = [3000, 8080]" })

Each traversal gets a fresh array, the same way = [] does. Computed defaults stay on the tuple form (["string[]", "=", () => ["localhost"]]).

Checklist

• Tests added in ark/type/__tests__/objects/defaults.test.ts
• Rebased onto current main
• Package build typecheck passes (pnpm -r --filter !@ark/docs build), which is what the core check failed on
• Full pnpm prChecks was not run locally; CI still runs lint, tests, and benches

[pullfrog]

Important

A unit-literal array default followed by trailing whitespace loses its type-level default value — the reconstructed literal collapses to never.

Reviewed changes

• Unit-literal array defaults — parseDefault now recognizes [...] after =, parsing each element as a unit literal at runtime (parseUnitLiteralArray/parseUnitLiteralElement) and mirroring the same grammar at the type level, then returning a fresh-array thunk like [] does (with Date elements cloned per traversal).
• Tests — 11 new cases in objects/defaults.test.ts covering both quote styles, interior whitespace and trailing commas, fresh-array semantics, and rejection of non-literal elements, unassignable elements, non-array bases, and trailing junk.

  ^{｜ Fix all ➔ ｜ Fix 👍s ➔ ｜ View workflow run ｜ Using DeepSeek Flash (free via Pullfrog for OSS) ｜ 𝕏}

[pullfrog]

ℹ️ Delta is clean — no new issues since the prior review.

Reviewed changes (since the prior review)

• enclosedUnit helper — factors the parseEnclosed call plus a hasKind("unit") guard out of both the quoted-string and d'/d" element branches of parseUnitLiteralElement. Behavior is unchanged (valid literals always produce a unit node, so the guard never fires) and it resolves the build typecheck that previously read .unit off an unnarrowed BaseRoot.

The trailing-whitespace finding from the previous review is not touched by this commit and remains open.

  ^{｜ Fix it ➔ ｜ View workflow run ｜ Using DeepSeek Flash (free via Pullfrog for OSS) ｜ 𝕏}

[yamcodes]

@pullfrog review

[pullfrog]

Important

Two inputs the runtime parser accepts are rejected at the type level — date elements and numeric tokens that JS rounds. Both are detailed inline.

Reviewed changes

• Unit-literal array defaults — parseDefault now recognizes [...] after = in string definitions, parsing each element as a unit literal at runtime (parseUnitLiteralArray/parseUnitLiteralElement) and mirroring the grammar at the type level (parseUnitLiteralArray/parseUnitElement), then returning a fresh-array thunk like [] does (with Date elements cloned per traversal).
• Trailing-whitespace fix — the latest commit routes the type-level branch through Scanner.skipWhitespace/trim so = ['a'] no longer collapses the default type to never; the prior review's finding is addressed.
• Tests — 11 new cases in ark/type/__tests__/objects/defaults.test.ts covering both quote styles, interior whitespace and trailing commas, fresh-array semantics, and rejection of non-literal/unassignable elements, non-array bases, and trailing junk.

  ^{｜ Fix all ➔ ｜ Fix 👍s ➔ ｜ View workflow run ｜ Using DeepSeek Flash (free via Pullfrog for OSS) ｜ 𝕏}

[yamcodes]

@pullfrog review

[pullfrog]

ℹ️ No blocking issues — both prior findings are fixed. Two minor follow-ups below.

Reviewed changes (delta against the prior pullfrog review)

• Date elements now reachable at the type level — parseUnitElement matches the d'/d" prefix before the generic quote branch, so Date[] = [d'2020-01-01'] resolves to Default<Date[], [Date]> instead of never.
• Inexact numbers infer as number — the number extends n ? never guard was dropped from inferUnenclosedElement, so tokens JS rounds (e.g. 9007199254740993) infer number, matching the runtime and the scalar default path.
• Tests — added "array default accepts date elements" and "array default accepts a number that is not an exact literal".

ℹ️ String-syntax docs still describe only empty collection defaults

ark/docs/content/docs/objects/index.mdx:167 states "An empty array or object can be defaulted directly in string syntax" and shows only = [] / = {}. With non-empty unit-literal arrays now supported, that paragraph and its example are incomplete. Note that a docs edit also requires regenerating ark/docs/public/llms.txt.

Technical details

# Document non-empty array defaults in string syntax

## Affected sites
- `ark/docs/content/docs/objects/index.mdx:167-175` — prose and example cover only `= []` / `= {}`.
- `ark/docs/public/llms.txt` — generated from docs `.mdx` files by `writeLlmsTxt()`; must be regenerated after any docs-content edit.

## Required outcome
- The string-syntax defaults paragraph/example should mention that `= ['a']` / `= [1, 2]` are accepted and produce a fresh array per traversal.

  ^{｜ Fix all ➔ ｜ Fix 👍s ➔ ｜ View workflow run ｜ Using DeepSeek Flash (free via Pullfrog for OSS) ｜ 𝕏}

[yamcodes]

@pullfrog review

[pullfrog]

✅ No new issues found.

Reviewed changes (delta since the prior pullfrog review)

The only commit since the prior pullfrog review (ff9033c6) is the docs update, so I re-verified the full feature at head rather than only the docs.

• Docs updated — ark/docs/content/docs/objects/index.mdx and its generated ark/docs/public/llms.txt now describe unit-literal array defaults alongside the empty-collection forms, with hosts/ports examples, resolving the prior review's open docs finding.

I confirmed the committed llms.txt is exactly what writeLlmsTxt() regenerates, and spot-checked type/runtime parity for bigint, escaped-quote, bracket-in-string, undefined, negative-number, and nested-array (rejected) elements — all consistent with the scalar path.

  ^{｜ View workflow run ｜ Using DeepSeek Flash (free via Pullfrog for OSS) ｜ 𝕏}