fix(json): keep contextual any and unknown serialization valid

[samchon]

Closes #2253.

This draft reserves the independently reproduced JSON contextual-serialization defect before implementation. The product invariant is that every child value accepted through any or unknown follows ECMAScript JSON context: object children that serialize to JavaScript undefined are omitted, while array and tuple children become null; successful text must parse as JSON.

Implementation has not started. The batch will add real-transform regressions across direct/factory and raw/is/assert/validate families, enumerate every shared joinder consumer, inspect emitted JavaScript, and mutation-prove the permanent oracle before the prospective and exact-merge integration gates.

Campaign constraints: no package version, tag, release, publication, or unrelated schema-interface change.

[samchon]

State of this pull request after the campaign consolidation.

#2253 is not included in the consolidated #2266 and stays open here. The branch now carries the analysis and the partial work as an explicitly incomplete commit, so nothing is lost, but it must not be merged as-is.

Root cause, re-derived from source. jsonStringifyProgrammer_decode emits JSON.stringify(input) for Any metadata, and JSON.stringify answers JavaScript undefined for a function, a symbol, and a toJSON that returns undefined while the value is still present. The object joiner decides omission from a test on the input (stringifyJoiner_regular_condition: undefined === input || "function" === typeof input), which cannot see a symbol or a toJSON result. The array joiner uses .map(...).join(","), where a mapped undefined and a hole both render as empty text.

The class is wider than the reported witness. A sparse number[] emits [,3], and a required property whose toJSON returns undefined emits {"k":undefined} — text that is not valid JSON at all. A hole exists at runtime whatever the element type declares, so this is not only an any/unknown concern.

What is missing, and why this was excluded rather than shipped.

1. The _jsonStringifyArray runtime helper is orphaned. StringifyJoiner.Array still emits input.map(arrow).join(",") and nothing imports or calls the helper.
2. The object-property half has no implementation at all, while the tests on this branch assert it.
3. The undefined: false oracle question is unresolved. Under that option typia may legitimately skip undefined checks, so native JSON.stringify is not an unqualified oracle there, yet the tests assert against it in both modes. Resolving that contract must come before the implementation, or the fix will be built to satisfy a wrong assertion.

Nothing here has been compiled or executed. It was written under a maintainer stop on all local building and testing; no cell of either test has ever run.

[samchon]

Implemented. This pull request now carries the fix, not the analysis.

Root cause. Omission was decided from a test on the input (undefined === input || "function" === typeof input), which cannot see a symbol or a toJSON result, and array elements were joined with .map(...).join(","), where a mapped undefined and a hole both render as empty text. The decision is now made from the serialized result, evaluated once — a toJSON may answer differently on a second call, so testing the input and then serializing is a different program.

Three positions, three answers, matching ECMAScript rather than one rule everywhere: _jsonStringifyProperty drops a member together with its separator; _jsonStringifyArray and _jsonStringifyElement write null, because an array position cannot be dropped without shifting what follows.

Fixed as a class, not as the reported witness:

symptom	position
{"k":undefined}	static member, index-signature member
[,1]	sparse array
[undefined,1]	array or tuple element with no serialization
{"a":1,}	trailing separator when the omitted member was last

That last one was reachable without any of this issue's inputs: the tail helper was skipped whenever the last member was declared required, but a required any member is still omitted when its value has no text. A declared toJSON whose return type admits undefined reaches the same state with no any anywhere, and a hole exists at runtime whatever the element type declares — so neither is confined to any/unknown.

Verification. The transform regression executes 354 runtime cases across direct and factory forms and all four stringify entry points, in default and undefined: false modes, comparing every result against native JSON.stringify as the oracle. The count is asserted, not the exit code, so a row that stops running cannot pass as a row that agreed. Fail-before was observed on this same regression — it reported malformed text for records, dynamic members, arrays, and tuples before the change, and the failures disappeared class by class as each position was fixed. The whole native/cmd/ttsc-typia package passes locally (106 s). The TypeScript suite added here exercises the real shipped helpers rather than the stubs, and CI owns it.

Change integrity. transform_helpers_test.go gains runtime stubs for the three new helpers. Its shared rewriter fails loudly on any unmapped typia/lib/internal/ import, so without them every transform test that serializes an array would stop resolving.

Deferred, not dropped. A non-callable toJSON twin is rejected by the declared type, but the checker admits it and the serializer then throws input.value.toJSON is not a function — so isStringify and validateStringify throw where their contract is to answer, never to throw. That is a callability rule rather than this contextual one, and mixing them would put two root causes in one diff. It is filed separately and keeps its own twin there.