checks: a check on a calculated field judges the value the write will store, not the payload's (#7544)

[NicoleNG18]

Cause

The generated controllers run validate() and repository.warnings() before save()/update(), but the calculatedOnCreate / calculatedOnUpdate assignments only happen inside those methods. A check on a calculated field, soft (severity: warn) or refusing, therefore compared whatever the caller sent: nothing on a create, a stale value on an edit. The issue's legally required "issued more than 5 days after the tax event" warning never fired for a REST write.

Change

This implements option (a) of the issue: evaluate the calculated expressions on the candidate row before the checks read it.

• The generated repository gains calculatedForCreate / calculatedForUpdate. Each returns a field copy of the submitted record carrying what the write will compute for its calculated fields:
  • create: after applying the authored defaults, as save() does (templates: defaultValue is applied after calculatedOnCreate on a server-side create - a line without vatRate computes vat 0 #7104);
  • update: after taking the system-owned fields from the stored row and recomputing the document totals, as update() does. So an expression like Balance = Total - Paid reads the stored Paid, never the payload's.
• Only the neutral Calc expressions are evaluated. A calculatedAction* may mint or mutate state, so it still runs only on the write itself.
• The submitted record is untouched. dropSystemOwnedOnCreate, save() and update() see exactly what they saw before, and what is persisted is still computed by the repository. An entity with nothing calculated gets the record itself back.
• All three controllers use the candidate row. In the power, my and partner controllers, on create and on both update branches, validate(), validateReferences() and warnings() now run on that candidate row.
• The assistant guide documents checks on calculated fields, using the issue's declaration as the example.

Verification

• New IntentCalculatedFieldChecksIT (HTTP-only; generates, compiles and runs the issue's declaration, plus a refusing compare on the same calculated field):
  • a create within the deadline passes silently;
  • a create 9 days late is answered 428, and nothing is persisted until the code is confirmed, after which it stores 9;
  • an update with a stale payload delay, and one with the delay omitted, are both judged on the recomputed 19;
  • a negative delay is refused with 400.
  • Against the unfixed templates the IT fails: the late create answered 200 instead of 428.
• These all pass on H2:
  • IntentSoftWarningsIT
  • IntentCheckMessageI18nIT
  • IntentEmissionCoverageIT (compiles and runs a broad generated model)
  • ModelGenerationIT
  • the two controller template ITs, whose validate(...) anchors now point at the candidate-row call
• ide-template (216) and engine-intent (1479) unit suites pass.
• mvn formatter:validate passes after wiping the formatter cache.

Not verified: the PostgreSQL leg.

Not in scope:

• Action-calculated fields: a check on one still reads the payload, by design (documented).
• Process task write-backs (Writer, intent: a task form's editable write-back skips field validation - an over-long value dead-letters the job and strands the record #7552): they write through updateProperties, which never recomputes calculated fields. Their validate therefore already reads the calculated values that stay stored.
• Roll-up capacity guards inside save()/update(): they still run before the calculated assignments. This PR changes only what the controllers' checks read.

Fixes #7544

🤖 Generated with Claude Code