fix(generation): the glue templates get every reference they render

[delchev]

Master is red: IntentEmissionCoverageIT fails on both DB legs since #6707 (run 31720936125, and every run after it). The reported failure is a ConditionTimeout on GET /services/java/emission-test/gen/emission/api/account/AccountController answering 404 - which is nowhere near the cause.

What actually broke

Two defects in the Java generation pipeline, both in generated glue code:

1. GlueGenerator.bindGenerate never bound fromGenFolder / fromProjectName. Velocity renders an undefined reference verbatim, so Generate.java.template emitted a literal gen.${fromGenFolder}.data.... The JavaScript this replaced computed both (generateUtils.js: crossModelSource ? the source model's folder : this project's).
2. RollupAggregates tested capacityField != null where the JavaScript tested truthiness. GlueIntentGenerator writes "" for an unused optional field, and "" is not null, so an unused capacity emitted parent. == null ? … : parent. ; - a member access with no member.

Why that 404s an unrelated controller: client Java compiles the whole registry in one javac task. A single unparseable generated file unregisters every controller in the application, so the symptom lands on an endpoint that has nothing to do with roll-ups or create-from. Worth remembering the next time a generated app 404s for no reason.

Why the tests let it through

ModelGenerationIT replaced the parity oracle when the JavaScript pipeline was deleted, and it checked rendered paths for surviving placeholders - never rendered content. And its orders.glue fixture declared no generates block at all, and omitted the optional roll-up keys rather than carrying them as "" the way the intent really writes them. The fixture exercised a descriptor shape no generation produces.

Changes

• the two fixes above;
• ModelGenerationIT rejects an unresolved ${reference} and a dangling member access in any generated .java. ${JavaTask} is excluded - that Flowable delegate expression is a deliberate literal. Verified red on the unfixed code, naming ${fromGenFolder} and ${fromProjectName};
• orders.glue made faithful to the intent's output: generates with a local and a cross-model source, the attachment family, businessKeyProperty, criteriaExpression, roll-ups carrying "" optionals, plus one populated capacity/balance/status roll-up. Completing it surfaced three more unresolved references immediately (all fixture gaps, now closed);
• RollupAggregatesTest pins empty vs populated vs absent optionals - red without the fix, 0.06s.

Verification

IntentEmissionCoverageIT   Tests run: 1, Failures: 0, Errors: 0   73.3 s   (was failing)
ModelGenerationIT          Tests run: 1, Failures: 0, Errors: 0   24.6 s
ide-template unit tests    Tests run: 72, Failures: 0, Errors: 0

formatter:validate and the release-profile javadoc check are clean.

Follow-up worth considering (not in this PR)

Velocity renders an undefined reference verbatim, which is how a forgotten context key becomes a Java syntax error instead of a missing value. Turning on runtime.references.strict for the model pipeline would make that fail loudly at generation time. It needs a sweep first - some templates may rely on an absent optional rendering as nothing - so it does not belong in a master-red fix.