A user update must not take system-owned fields from the payload

[delchev]

Stacked on #6687 (only for a conflict-free diff; independent otherwise — retarget to master once that merges).

The generated update() persisted the whole incoming row, so a partial payload — the UI header form PUTs only the fields it edits — erased every column the write path owns. Reproduced on a production tenant (2026-08-12): a draft invoice header edit nulled Paid and wrote Balance 0, and the customer-facing PDF printed "amount due: 0" on an 8,556 invoice. Two defects compounded:

• nothing preserved the system-owned columns, so the roll-up target Paid (written only by the allocation listeners) took the payload's null;
• the expressionUpdate recompute (Balance = Total - Paid) ran BEFORE recalculate(), reading the payload's nulls as zeros — Balance persisted 0 while recalculate() then repaired Net/Vat/Total from the reloaded items, which is exactly why the corruption looked impossible: correct totals next to a nulled Paid and a zero Balance.

Changes (template-application-dao-java, Repository.java.template)

• update() reloads the stored row once and takes the system-owned values from THERE, never from the payload: isReadOnlyProperty fields (author readOnly, roll-up targets, the document number and uuid — which also covers ProcessId and the audit columns) and aggregate footer fields with no update-time recompute (Net/Vat/Discount/Total/Paid).
• The expressionUpdate/actionUpdate assigns move AFTER recalculate(), so Balance = Total - Paid reads the resummed Total and the preserved Paid.
• Deliberately NOT preserved: a calculated create-only field that stays user-editable (a Currency relation defaulted from the company) carries neither flag, so a user's edit of it is respected.
• Safe against workflow writes by construction: every system writer (number stamp, status transitions, roll-ups) uses the targeted updateProperty / updateProperties / updateDerived primitives, which bypass update() entirely — the fix(intent): trigger ProcessId write-back via targeted single-column update — kill the stale-snapshot race #6226/fix(intent): setter/writer delegates use targeted updateProperty writes #6306 lost-update family, user-update edition.

Verified on a live instance (registry wipe + template reseed + regen of sales-invoices and timesheets): the emitted update() preserves Number/Net/Vat/Discount/Total/Paid/Uuid/ProcessId/audit and recomputes Balance after recalculate(); the runtime reproduction (create invoice + item, PUT a header-only payload) keeps Paid 0.00 / Balance 120.00 / Number intact where the previous build persisted Paid null / Balance 0. Client-Java batch: 256 units, 261 class files.

🤖 Generated with Claude Code