templates: apply a field's defaultValue before the create-time calculations (#7104)

[delchev]

defaultValue: was the column's DB DEFAULT and nothing else on the server, so the database supplied it at INSERT — after the generated repository's create-time calculations had already run in Java and read a null.

On BusinessIntents STA, a purchase-order line posted without VatRate (vatRate: { defaultValue: 20 }, vat: calculatedOnCreate: "round(Net * VatRate / 100, 2)") stored VatRate 20 from the default and Vat 0 from the calculation that reads it; only a later no-op PUT — whose recalculation sees the stored default — put the two in agreement. The generated form hid it, because the item dialog seeds the same default and posts it explicitly. So it was every REST caller, import and server-side create that silently got a wrong total.

The fix

Repository.java.template gains an #applyDefaults() macro, emitted as the first statement of save(): a column the write left empty gets its authored default, in a literal of the property's own type, before the label, the roll-up/aggregate guards, the document checks and the calculatedOnCreate expressions read it.

• save() only. An existing row is never re-defaulted, so a value the user deliberately cleared stays cleared through update().
• The DB DEFAULT stays, for a row that reaches the table by any other route.
• A numeric default is parsed from its authored text (new java.math.BigDecimal("20")) rather than inlined as a numeric literal, so an author's 8.0 on an integer column fails that one create instead of failing the whole generated build.
• A string default is accepted in either authoring shape — bare (DRAFT, what the item dialog seeds) or SQL-quoted ('DRAFT', what a working DB DEFAULT needs, since the value reaches the DDL verbatim) — and both yield the string the column would hold.
• A date/time/timestamp or binary column is excluded: its DEFAULT reaches the DDL verbatim and is typically a SQL expression (CURRENT_DATE, now()), which has no Java stand-in. There the DB DEFAULT remains the only leg.

A to-one relation's init: is the same mechanism (it lands as dataDefaultValue on the FK), so an initial status is now assigned by the repository too — the value the create-time postings and process triggers see, not the one the database was about to fill.

Verification

• New IntentEngineIT#an_authored_default_is_applied_before_the_create_time_calculations — a decimal, a boolean and a string default; each guarded on null; the decimal assigned before the Calc.eval that reads it; and exactly once in the file, so update() does not re-default.
• IntentEngineIT new test + a_required_value_is_refused_by_name_instead_of_by_the_database + calculated_field_action_emits_an_imports_backed_callout_in_the_repository — 3/3.
• IntentEmissionCoverageIT — green. It exercises this at runtime through a real HTTP create: a document posted without its init:-defaulted status still answers 200 and echoes the applied default.
• ModelGenerationIT — green (every template still renders its model).
• Full mvn install — BUILD SUCCESS.

Fixes #7104

🤖 Generated with Claude Code