Report preview/PDF divergence: refund note renders before the other allocated-amount labels in the preview, after them in the PDF

[steilerDev]

[product-owner] Follow-up from the PR #2015 review (product-owner, non-blocking). Pre-existing defect, newly visible because #1911 makes multi-label rows common.

As a homeowner checking the on-screen preview before exporting, I want the preview to show the amount annotations in the same order as the PDF, so that what I approve is what the bank receives.

Parent Epic: none — parent-less Bank Report Wizard cluster.
Priority: Should Have

Problem

The allocated-amount annotations render in different orders on the two surfaces:

Surface	Order
PDF (overviewPdf.ts, allocated-cell runs)	(Deposit) → (partial) → (less deposit) → (refund)
Preview (ReportContentEditor.tsx L331 vs L335–352, and L443 vs the mobile equivalents)	(refund) → (Deposit) → (partial) → (less deposit)

The refund note is emitted before the other three in the preview and after them in the PDF.

This predates #1911 — it has been true since the inline labels landed in #1959. What changed is exposure: before #1911 a row rarely carried more than one label, so the divergence was hard to see. #1911 makes (Deposit) (partial) and (Deposit) (less deposit) ordinary, so a refund row now visibly disagrees between the two surfaces.

The preview is the approval surface — the user reads it and then exports. Preview/PDF parity is an explicit property of this feature (#1965 AC 3.1 asserts it for the legend). It should hold for the row annotations too.

Acceptance Criteria

• 1.1 The preview and the PDF emit the allocated-amount annotations in the same order. The PDF order is the reference — (Deposit), (partial), (less deposit), (refund) — because it is what the recipient receives.
• 1.2 The fix applies to both preview sites: the desktop table and the mobile cards.
• 1.3 A test asserts the order on both surfaces from a single fixture carrying all four annotations, so the two orders cannot drift apart again. Asserted against a real render per the realRender.test.ts pattern, not a key-echoing t mock.
• 1.4 No string changes, no styling changes, no change to which annotations appear — ordering only.
• 1.5 Verified in en and de.

Notes

Scope boundary: ordering only. Whether four annotations on one row is too many, and whether they fit the 75 pt column, is not this issue — the geometry is covered by #1911 AC 4.5's measured four-run maximum.

Related: #1959 (introduced the inline labels), #1965 (parity requirement for the legend), #1911 (made the divergence visible).