Fix discarding identification and audit

[TIVMOF]

This PR:

• fixes resolves: batches relation + outcome + status into one write - a rejected status move discards the identification and the audit trace #6806

resolves: throws away the identification when the status move is rejected

resolves: batched three semantically independent values — the resolved relation, the outcome:
trace, and the routing status — into ONE updateProperties call. The generated DAO runs the
lifecycle: and checks: gates against the post-write row before persisting anything
(Repository.java.template: values applied in memory → enforceLifecycleMove → enforceChecks →
super.updateProperties), so a rejected status move discarded the relation and the trace with it.

The system did the work, got the right answer, and threw all of it away — including the audit field
whose entire purpose is recording what happened. And because the listener dispatcher gave no
explanation, a reviewer could not tell this apart from "the lookup never ran".

The fix

stamp() now writes twice, in this order:

1. The result — the resolved relation + the outcome trace. This is the work: the register was
   read, exactly one row covered the date, this is the answer.
2. The routing status, separately.

A rejected transition can no longer destroy the identification, and the audit trace is the last
thing a failure can take.

The routing write catches ValidationException specifically. Retrying cannot help — nothing about
the record changes by re-reading the register — so rethrowing would only burn the redelivery budget
(now real, since #6830) and dead-letter. Instead it logs and amends the trace to
<outcome>-notRouted, so a routed-but-rejected record stays distinguishable from a fully processed
one. A genuine DB failure is not caught and still propagates and retries.

Both writes stay targeted, so no -updated re-fires and no concurrent write to another column is
reverted.

Also here

A parser guard that the outcome: field is long enough for the values written — 9 normally, 19 once
any outcome routes by setStatus. Truncation happens at the DB where nothing reports it, which
would have reintroduced the same silent loss through the back door. Only bites an author who
explicitly narrows the field (the default VARCHAR length is 100).

Verification

• IntentEngineIT.resolve_writes_the_result_before_the_routing_status — asserts the write order, that
  the status is not in the batched map, the ValidationException catch, the amended trace, and
  the log line.
• ResolveIntentTest.rejectsAnOutcomeFieldTooShortForTheValuesWritten — red-first verified; also
  asserts the non-routing case still accepts a shorter field.
• engine-intent 692/692, formatter:validate clean.
• Template rendered through real Velocity in all four #if shapes (writesStatus × outcomeProperty).

Not run: the new IT. engine-camel's Maven plugin is unresolvable in my offline environment,
which blocks the whole failsafe suite. CI will be its first execution.