tests: IntentPostingAmendIT's redelivery step cannot tell a no-op from a rewrite - it asserts line count and amounts, not identity (#7162 follow-up)

[delchev]

Describe the bug

PR #7244 (#7162) adds IntentPostingAmendIT and its body claims the test proves that "a redelivery with nothing edited changes nothing, so the loop is not 'rewrite on every event'". The step that is meant to prove it (IntentPostingAmendIT.java, the RejectDoc -> IssueDoc pair with no edit in between, followed by assertEquals(entry, onlyEntryOf(doc)); awaitLines(entry, 1260.0f);) cannot distinguish a no-op from a rewrite:

private void awaitLines(int entry, float amount) {
    ... .body("", hasSize(2))
        .body("findAll { it.Debit == " + amount + " }.size()", equalTo(1))
        .body("findAll { it.Credit == " + amount + " }.size()", equalTo(1)),

The rewrite path (Posting.java.template:246-259) keeps the same header (targetRepository.update(target)) and deletes + re-inserts the lines. So after a redelivery that rewrote everything, the entry id is unchanged and there are still two lines with the same amounts: both assertions are true before the async handler even runs, and they stay true whether it is a no-op or a rewrite. A Posting.java.template that rewrote on every event (the amendment semantics #7071 deliberately bounded) passes this step unchanged - the pattern-3 ("proves compilation, not behaviour") shape the umbrella issue #7162 is about, inside the PR that closes it.

The other three outcomes of the class are real (in-place rewrite to 1260 asserted by amount, a single entry, the was NOT rewritten refusal awaited on the app.gen.events logger).

Expected

Capture the two line ids after the first amendment and assert the redelivery leaves those ids in place (and the header's updatedAt, if audited, untouched). Then the step can go red on a rewrite-on-every-event regression.

Minor, same PR: IntentCompositionCascadeIT's "the leg the cascade had ALREADY deleted comes back" narrative depends on findAll(Criteria.eq(fk,id)) visiting leg 30 before leg 40 (no ORDER BY in Repository.java.template:1201-1204); the final assertLegsOfTrip(chained, 2) holds either way, so on a database that visits 40 first the rollback claim is untested rather than proven. An ORDER BY in the cascade's read, or a fixture where the refusing child is unambiguously visited last, makes it a proof.