Port jtd-esm-codegen onto the incubator main as generated code

[simbo1905]

What

Bring the jtd-esm-codegen capability back into the reactor on the current main: the work exists on the stale jdt-to-esm branch (module jtd-esm-codegen, 316/316 official json-typedef-spec conformance, 43 additional tests, module depends only on the core API), but that branch predates the complete sandbox→incubator package move and the public API renames (bool()→asBoolean(), string()→asString(), elements()→asList(), members()→asMap(), valueOrNull→tryValue, etc.), and its deck (release-deck-jtd-esm, 28 Aug 2026) is out of date on those counts.

The module compiles RFC 8927 JTD schemas into standalone ES2020 ESM validators (single validate(instance) export with {instancePath, schemaPath} error indicators) for JavaScript and browser consumers — a target the JVM bytecode codegen does not cover.

Why

• The capability is proven (316/316 conformance, acceptance bar ≥314) but unreachable from main; merging the stale branch wholesale would drag pre-rename packages and old CI counts.
• Recreating the module on current main is cheaper than rebase-merging: main's divergence is additive, and the generated validator must emit generated code (a specialized validator per schema, consistent with the json-java21-jtd-codegen approach) rather than shipping an interpreter/state machine at runtime.
• The conformance harness (all 316 official validation.json cases executed via GraalVM Polyglot) and the spec hardening (schema-path semantics, string escaping, normative rejections) should be preserved through the port.

Done means

• jtd-esm-codegen module present in the reactor on incubator-package main, using the current public API names.
• Generated ESM validators are generated code, not an embedded interpreter/state machine.
• Full reactor build green; CI expected test count updated to the new total; module registered in AGENTS.md and README module documentation.
• 316/316 official conformance preserved (GraalVM Polyglot harness).