Fixing invisible document numbers

[TIVMOF]

This PR:

• fixes Task-form Writer and stampOn:issue Numbering persist through silent targeted writes - no -updated is ever published #6809

Task-form edits and stamped document numbers are invisible downstream

Two generated writers persist data that is meaningful to the rest of the system through the silent
targeted primitives, so notifications:, integrations:, outbound: and every other -updated
consumer cannot observe them:

Writer	Site	What it writes silently
task-form writer	events/Writer.java.template:59	every field the user edited in the task
number: { stampOn: issue }	events/Numbering.java.template:43	the document number

The Writer's javadoc even asserted the silence was correct — "A workflow-driven system write that
must not re-fire onUpdate reactions". That is the actual defect: these are a person's edits.
onUpdate reactions exist precisely to react to what a reviewer changed, and nothing could see it.

The masking effect is what made it survive

BpmnIntentGenerator orders after-task delegates [writer, setter, stepEvent] (:688-700). If the
task also carries a setRelationField, the setter's post-write reload sweeps the form edits into its
-transitioned payload by coincidence — so the same authoring model is observable or not
depending on whether an unrelated status setter happens to exist on that task. A task with no setter
loses the edits entirely.

The same accident covers numbering: the stamped number only reached consumers via a preceding
setter's reload. That is also the bug the SetField deferral comment already records — "an
auto-posted entry used to catch the create-time UUID placeholder".

The fix

Both writers now follow the SetField.java.template pattern exactly: guard on the update count,
re-load so the payload is the committed row, then publish -updated through
Process.executeAfterCommit.

The deferral is load-bearing, not decoration. A consumer re-loads the record on receive, so
publishing inside the Flowable command would race the remaining steps of the same synchronous chain —
which is the precise failure the numbering placeholder bug was.

GlueGenerator.bindNumbering gained one key: it copied only the sanitized perspective into the
Velocity context, and an event topic is built from the raw one.

On the systemic option

The issue suggested switching these to updateDerived (targeted write + -updated, DAO :485-497).
That would be wrong here. updateDerived publishes eagerly, which is right for its callers —
rollup and aggregate MessageHandlers, outside any BPMN command — and wrong for a JavaDelegate
running inside one, for the reason above. Following SetField is the correct shape.

Documentation

The third ask — "an author cannot tell by reading the guide which constructs are observable" — is now
a table in intent-assistant-guide.md under the event-axis section: what each write publishes and
what can bind to it, plus the deliberately-silent cases and why (the trigger's ProcessId write-back,
an expansions: child count, and a resolves: lookup would each re-trigger their own handler).

One silent write I found and did not change: a document's header totals, recomputed by
Repository.recalculate(Object) via the base super.updateProperties (:769). It is defensible —
the line item's own create/-updated/-deleted already fires — so the guide now says to bind the
reaction to the line, not the header. Worth its own issue if that is not the intended contract.

Verification

• IntentEngineIT.editable_task_form_fields_are_coerced_to_their_java_type_on_write_back — extended
  with the topic, the deferral, and write-before-reload ordering.
• IntentEngineIT.numbering_stamp_publishes_the_stamped_document_number — new; the stampOn: issue
  delegate had no emission coverage at all.
• ide-template 77/77, engine-intent 691/691, formatter:validate clean on all three modules.
• Both templates rendered through real Velocity (Writer, and Numbering in its per / no-per
  shapes) — brace- and paren-balanced, findById(Object) signature confirmed against
  JavaRepository:123.