Add optional transaction-count breakdown per status (SPS 2026)

[claude]

Closes #7

Summary

Issue #7 bundles several SPS/CBPR+ 2026 changes. This PR implements the one item that was concrete and unambiguous enough to design without further working-group input:

Status Report 4.3 — NbOfTxsPerSts changed from "not defined" to "optional"
Added an optional numberOfTransactionsPerStatus array to PaymentSubmissionStatus and StandingOrderSubmissionStatus (used by GET /single-payments/{submissionId}/status, GET /payment-requests/{submissionId}/status and GET /standing-orders/{submissionId}/status). Each entry carries a statusCode (reusing the existing transaction-level status codes already defined on PaymentInstructionItemStatus) and a numberOfTransactions count, so a server can report how many of the underlying transactions were assigned a given status without having to enumerate every transaction individually. This is purely additive — existing clients that ignore the new field are unaffected.

Not implemented in this PR — left for the working group

• Cash Management 5.1 (structured RemittanceInformation): the issue itself poses this as an open question ("To decide: … Which additional attributes for structured Remittance Information should be included?") with only examples (RfrdDocInf, RfrdDocAmt) rather than a definitive list, and asks which release the change should target. Since the issue explicitly leaves the choice of attributes open to the working group, I left this out rather than guessing a specific attribute set. Left a comment on the issue explaining this and asking for the concrete attribute list.
• Discontinuation of euroSIC (item 2) and pain.002 Tracker Data (item 4.2): the issue author states these have no impact on the current specification, so no change was made.

Assumptions

• numberOfTransactionsPerStatus is modeled as an array of {statusCode, numberOfTransactions} objects (no control-sum field), since the issue only describes "indicates the number of transactions reflected by the respective status" and no monetary breakdown was requested.
• The statusCode enum for the new object reuses the transaction-level codes already used on PaymentInstructionItemStatus (ACCC, ACCP, ACSC, ACWC, RJCT) for consistency with how individual transaction statuses are already represented in this API.
• This change only touches the payment API (PSS); the account API (AIS) has no equivalent status-report concept.