feat(ide-template): execute model generation in Java

[delchev]

What

Ports the template-generation "generation utils" from JavaScript to Java — the first of three stacked
PRs described in GENERATION_UTILS_JAVA_PLAN.md (added here).

Ported, all into components/ide/ide-template/.../service/model/:

• generateUtils.js → ModelGenerator + GlueGenerator: the 47-case dispatch, the ~28 entity
  partitions, per-collection rendering, the administration surface, the whole-model fallback, and both
  translate actions. GlueGenerator carries the 22 glue collections, including the roll-up coalescing
  and the four aggregate variants.
• parameterUtils.js → ModelParameterProcessor: the per-entity and per-property derivation pass,
  the dropdown lookup URLs, the personal and partner surfaces, label parts, perspectives and roles.
• generate.mjs → ModelGenerationService: model read, cross-project entity-extension folding,
  the targeted gen/<sub> scrub derived from the actual output paths, the .gen descriptor, publish.

Naming collapses into one implementation each: a new NamingHelper in commons-helpers, which both
IntentNaming and the generation pipeline delegate to.

What this does not do

Nothing is switched over. The JavaScript endpoint is untouched and is still the only one any consumer
calls; the Java pipeline is a service and is not yet exposed over HTTP. Consumer switch-over and the
in-process intent execution are PR 2; deleting the JavaScript is PR 3.

Why it can be trusted

GenerationParityIT (HTTP-level, no browser) runs both pipelines over 11 fixture/template pairs
and asserts every produced path and every byte of content matches — the .gen descriptor included,
because its formatting is content-compared across regenerations:

Fixture	Templates
a rich model (47 entities, depends-on, master/detail, projections)	schema, DAO-Java, REST-Java, full stack
a simple model	schema, full stack
the simple model + a sibling project contributing an entity extension	schema, full stack
process glue (triggers, notifications, roll-ups incl. coalescing, keyed aggregates, setters)	glue-Java
a form	Harmonia form builder
a report	Harmonia report

The extension case additionally asserts the merged column reaches the output, so "both pipelines
dropped it" cannot pass as parity. Plus 45 new unit tests over the naming rules, the type mapping, the
JSON writer and the derivation pass.

Four things the parity harness turned up

1. MustacheGenerationEngine mutates the parameter map it is handed, adding an indexed twin of
   every collection under a _-suffixed key, recursively. No caller had noticed, because they all
   reached it through a fresh map — the JS facade deserializes per call. Handing it a live graph left
   those artefacts in the parameters and from there in the .gen descriptor, where they would
   accumulate on every regeneration. Worked around by copying the context per invocation; the engine
   not mutating its input would be the better fix, but that changes shared platform behaviour and
   belongs in its own change.
2. Every number in the parameter graph must be a Double — the graph reaches a template engine as
   the result of parsing JSON with Gson, so that is what the templates have always seen.
3. Absent is not null — assigning undefined drops the key from the serialized parameters, while a
   Java null keeps it.
4. IntentNaming.humanize is not the JS humanizeName: it additionally splits on - and _.
   The plan assumed they were the same function and said to verify the override maps; the maps match,
   the algorithms do not. They decompose cleanly instead — the JS function is the per-segment core —
   so both forms now live in NamingHelper as one implementation each, with no behaviour change on
   either side. Whether generation should adopt the separator-aware form is a separate decision: it
   would relabel generated artefacts and needs its own regeneration sweep.

Scoped out, deliberately

template-mapping-java is not handled by the Java pipeline — its preparation is a mapping compiler
rather than marshalling. It stays on the JavaScript path and must be ported before PR 2 switches the
.mapping consumers. The Java pipeline rejects it by name rather than generating something partial.

Verification

• GenerationParityIT green (11/11 cases byte-identical)
• 52 unit tests green (45 new, plus the pre-existing IntentNamingTest, which guards the delegation)
• mvn formatter:validate clean on every touched module (cache wiped first)
• javadoc clean under -P release on the touched modules
• full reactor compile green (-pl tests/tests-integrations -am, 305 modules)

Not run locally: the full integration suite, and the PostgreSQL leg. This change touches no SQL, and
the new IT is untagged so it lands in the PR smoke set.

🤖 Generated with Claude Code