VoP: only reject stepwise report delivery when it actually happens

[fds2610]

I have implementes SEPA transaction in my "Finanzmanager" Software thanks to nemiah/phpFinTS. Here is my solution for some missing details with comdirect german bank including following PR#585:

The HIVPPS parameter "Art der Lieferung Payment Status Report" (V/S) describes how the bank
splits the pain.002 message if it uses the Aufsetzpunkt mechanism, which it typically only
does for large batches:

Der BPD-Parameter gibt an, ob die pain.002-Nachricht bei einer Aufsetzpunktbehandlung
vollständig oder schrittweise übertragen wird.

— FinTS_3.0_Messages_Geschaeftsvorfaelle_VOP_1.01_2025_06_27_FV.pdf, chapter D

Rejecting S while building the very first HKVPP is therefore too early: it makes every
transfer fail for banks that announce stepwise delivery, even for a single transfer where the
result comes back right away and no Aufsetzpunkt is involved at all.

comdirect is such a bank. Its BPD says:

HIVPPS:7:1:3+1+1+0+20:J:S:N:N:sepade.pain.002.001.10.xsd:HKIPZ:HKCUI:HKCCS:HKCDE:HKCDN:HKCSE:HKCSA:HKIPM:HKCCM

So every transfer ended in UnsupportedException: The stepwise transfer of VOP reports is not yet supported, although the bank returns the VOP result in a single response.

What this changes

The check moves to where it matters, VopHelper::checkPollingRequired():

• If the bank sends an intermediate delivery of the report, "vollständige Lieferung" (V)
  means each delivery contains all data accumulated so far, so the intermediate one can be
  discarded and we keep polling for the final report. Previously this raised
  UnexpectedResponseException.
• Only for "schrittweise Lieferung" (S) would the client have to stitch the deltas together.
  That is still not implemented and still raises UnsupportedException, just at the point
  where it is actually true.
• An Aufsetzpunkt together with a vopId remains an unexpected response, since the
  specification says the VOP ID is only set in the final HIVPP of such a sequence.

checkPollingRequired() needs the BPD for this, so it takes it as a third parameter now. The
only caller is FinTs::processServerResponse().

Tests

SendTransferVoPStepwiseTest runs all existing VOP scenarios against a bank that announces
stepwise delivery, by overriding the BPD in the test base (new anonymousInitResponse() hook,
so the very long message does not have to be duplicated). Both variants additionally cover an
intermediate report delivery: discarded for V, rejected for S.

Verified against comdirect: with this change a single transfer completes through VOP
confirmation and TAN.

Related: #477

[nemiah]

Please resolve conflicts

[fds2610]

Rebased onto current master, conflicts resolved.

The conflict came from #585 (now merged), which added its tests at the same spot in SendTransferVoPTest. Both sets of tests are kept, testIntermediateReportDelivery() simply moved behind them. No change to the actual patch — the diff is still the same 110/-11.

As a side effect SendTransferVoPStepwiseTest now also inherits the two single-transaction-result tests from #585, so those are covered for "schrittweise Lieferung" (S) as well. CI is green.

[fds2610]

Verified against comdirect in production today: with this patch a real transfer completes end to end.

The BPD announces stepwise delivery:

HIVPPS:7:1:3+1+1+0+20:J:S:N:N:sepade.pain.002.001.10.xsd:HKIPZ:HKCUI:HKCCS:HKCDE:HKCDN:HKCSE:HKCSA:HKIPM:HKCCM

But the response to HKCCS already carries the result for the single transaction, and there is no Aufsetzpunkt anywhere in the dialog (VOP id and IBAN redacted):

HIVPP:7:1:5+@57@<vop-id>+20260904:232011++++DE00XXXXXXXXXXXXXXXXXX::::RCVC+Sollte Ihre ...

So "Art der Lieferung" never comes into play for a single transfer — the report is not split across deliveries at all. Before this change the transfer was rejected while building the very first HKVPP, so it never got that far.

[nemiah]

If an LLM was used, see #586