fix(intent): a count roll-up recomputes when a child changes parents

[delchev]

Closes #6820.

What was wrong

GlueIntentGenerator.buildRollups emitted the -updated handler only for op: sum and op: latest:

rollups.add(rollupEntry(base, className + "RollupOnCreate", ""));
if (sum || latest) {
    rollups.add(rollupEntry(base, className + "RollupOnUpdate", "-updated"));
}
rollups.add(rollupEntry(base, className + "RollupOnDelete", "-deleted"));

op defaults to count, so the default case was the excluded one — and it is the case that needs the update handler most. A child changes parents by an ordinary edit of its parent relation (a loan reassigned to another member, a task dragged to another sprint): no child is created, none destroyed, so nothing recomputed. The parent that received the child never counted it, and because a roll-up is recompute-on-event the counter stayed wrong until some unrelated child of that parent happened to be created or deleted — an off-by-one counter, which reads as plausible.

The fix

Emit the update handler for every op. Nothing else changes: the recompute is the same query in all three cases and reads the child rows back from the store (findAll(Criteria.create().eq("<Fk>", entity.<Fk>))), so the handler is idempotent — an edit that touched nothing the roll-up reads finds the value unchanged and, thanks to the existing changed guard, writes nothing and publishes no parent update. The event set is a property of the construct, not of the aggregation, so the emission is no longer op-specific.

The parent the child moved away from is still stale: the update event carries the row's current FK only. That needs roll-ups to consume the -rekeyed event (the mechanism aggregates already uses) and is #6819; this fix alone makes the new parent correct.

Tests

• GlueRollupCountTest (new, engine-intent) — a count roll-up emits exactly three descriptors, binding "" / -updated / -deleted, all carrying the same op and recompute criteria.
• IntentEngineIT.rollup_generates_create_and_delete_listeners_that_recompute_the_parent_count — now also asserts the generated LoanMemberRollupOnUpdate binds intent-test-Loan-Loan-updated and recomputes exactly like the create handler.

Verified locally: IntentEngineIT 50/50, IntentEmissionCoverageIT + ModelGenerationIT green, engine-intent + ide-template unit tests 690/690, formatter:validate clean, -P release javadoc clean.

Docs

• components/engine/engine-intent/CLAUDE.md and the intent assistant guide (in this PR) — three handlers, and the remaining -rekeyed gap.
• The stale javadoc on GlueGenerator.rollups ("a count roll-up contributes no update entry, so the update handler ends up sum-only") now explains why the event is part of the coalescing key.
• dirigible.io: docs(intent): a count roll-up recomputes on child update too dirigible-io/dirigible-io.github.io#202.
• Spec proposal: spec: a roll-up recomputes on the child's update too IntentFile/intent-specification#40 · intentfile.org: docs: a roll-up recomputes on the child's update too IntentFile/intentfile.github.io#31.

🤖 Generated with Claude Code