intent: a deleted payment gives its allocation back (#7061)

[delchev]

The defect

A settlements: block bound the allocation to the payment's create, correction and re-key moments - but not to its delete. Nothing else takes the junction rows with the payment: the junction's FK to it never becomes a database constraint on this platform (referential integrity is a business-layer check), so there is no cascade, and when the payment is cross-model its owner model knows nothing of this settlement and does not own the rows.

So deleting a CustomerPayment (the path a user actually takes to reverse one) left its SalesInvoiceCustomerPayment rows behind as orphans pointing at an id that no longer existed, the invoice stayed PAID with a zero balance forever, and the payments panel rendered the orphan as a bare id. #7016 / #7022 modelled the same QA scenario as deleting the allocation and fixed that path; the moment that reaches it was never bound.

The fix

buildSettlementCleanups emits one handler per settlement - <Name>OnPaymentDeleted, rendered from a new SettlementCleanup.java.template on the settlementCleanups glue collection - bound to the payment's -deleted topic. It deletes every junction row of that payment through the generated junction repository, so each row's delete event fires and the paid roll-up recomputes the invoice's paid / balance / status exactly as for a hand-deleted allocation, relinquishing PAID / PARTIAL via the #7022 path.

Notes on the shape:

• Unlike the re-key handler it needs no payment repository - only the key off the delete payload - so it is emitted for a cross-model payment too, which is the case the issue was found in.
• The delete event is published after the payment row is gone, so a re-delivery finds an empty allocation set: idempotent with no guard of its own.
• The payment-side roll-ups are unaffected - their parent no longer exists and the roll-up handler returns on a null parent, so no -updated re-fire and no re-allocation.
• An intent with no settlements: generates byte-identically.

Tests

• GlueSettlementRekeyTest - the cleanup entry exists on -deleted with the expected class name, and still exists for a cross-model payment (unlike the re-key listener).
• IntentEngineIT#settlement_generates_on_payment_listener_and_on_invoice_delegate - the rendered AutoSettleOnPaymentDeleted.java binds <project>-Payment-Payment-deleted and deletes the payment's rows through the junction repository. Run locally: green.
• mvn test on engine-intent + ide-template: 1071 tests, 0 failures. formatter:validate and the release-profile javadoc pass on both modules.

Docs: the settlements section of the DSL reference on dirigible.io (companion PR).

Fixes #7061