intent: a scheduled reminder can record what it sent and escalate by days past due (#7276)

[delchev]

The problem

A schedules[].notify could mail but not record, and could not tell a document three days
overdue from one ninety days overdue. Two consequences, both reported in #7276 from codbex
sales-invoices, which models dunning correctly at the data level and defers the behaviour in its
own comments:

• the reminder history (and the report over it) filled only from manual clicks, never from the
  automated sends - so it was not a record of what went out;
• a seeded Second reminder / Final notice was inert: only the first level was ever applied,
  and the same flat wording went out every Monday forever.

The change

1. notify and generate may be declared together. Per matched row the target record is
created first and the mail goes out after it, in the same fail-soft try, and the generate's
unique: natural key gates both - a row whose record already exists is skipped entirely, mail
included. unique: is therefore required on a combined schedule (refused without it): without a
key the tick re-mails every matched row on every tick and writes another record beside each send.

2. escalate: - a days-past-due ladder.

escalate:
  ladder: ReminderLevel      # the levels (a kind: setting table)
  after: daysAfterDue        # the integer threshold on the ladder
  since: dueOn               # the row's date the days are counted from
  into: Level                # where the chosen level is written on the target
generate:
  to: PaymentReminder
  unique: [SalesInvoice, Level]   # (document, level) - each level goes out ONCE
  map: { SalesInvoice: id }
  defaults: { sentOn: now }
notify:
  to: contactEmail
  subject: "Invoice {number} - {escalation.name}"
  body: "{escalation.wording}"    # the level's own text - per-level wording

The row is placed at the highest level whose threshold it has passed; one that has passed none is
left for a later tick (and counted, so the log says so). The level joins the natural key, which is
what advances First -> Second -> Final as the document ages, each sent once.
{escalation.<field>} reads one field of the chosen level in the subject and body.

What is refused, and why

Every way the ladder would read as working and not be:

refused	because
escalate without a generate	nothing distinguishes a level already sent from one still due, so the top level reached would re-send every tick
a unique: key that omits into	the guard finds the FIRST reminder of a document forever - the exact symptom reported
a non-integer after, a non-date since	the ladder counts whole days
an into that does not point at the ladder, or that map/defaults also assigns	two answers to which level applies
a cross-model source or generate target	the days are counted off the row's own date, and whether the target property points at this model's ladder is knowable only here
{escalation.<field>} with no ladder, or a field the ladder does not declare	an unresolvable placeholder degrades to its own literal text - the characters {escalation.name} would be mailed to the customer

Implementation notes

• The job template is now one row body driven by generates / notifies flags instead of two
  branches. action stays in the glue and the binder falls back to it, so a .glue written before
  this renders exactly what it always did (asserted).
• The chosen level is frozen into an effectively final local before the generation lambda closes
  over it.
• The two halves' one-hop relation loads are merged and deduplicated: the loop declares each
  local once, so a relation both the recipient and a map source reach is loaded once.
• The escalation's reserved locals are held in a set of their own rather than folded into
  CREATE_FROM_LOCALS, so an ordinary relation named Level is not refused on every create-from.

Verification

• engine-intent unit suite 1253 tests green, including the new ScheduleEscalateIntentTest
  (10) and GlueScheduleEscalationTest (6).
• IntentEngineIT 81/81 green, with a new test pinning the generated job's ordering: ladder
  lookup before the guard, the level in the key, the guard continueing before the send, one try
  around the whole row, both summary lines.
• IntentEmissionCoverageIT green with an escalating dunning tick added to its fixture - so the
  combined job is COMPILED by the real publish (client-Java javac), which is the only thing
  that proves the typed escalation local builds against the generated entities.
• IntentCrossModelScheduleSourceIT 5/5 green.
• mvn formatter:validate green with the formatter cache wiped.

Not verified: a live cron firing end to end (a tick is scheduled, not triggered, in these suites) -
the fixtures use crons outside the test window by design.

Fixes #7276

🤖 Generated with Claude Code