Fix VoP handling for banks that do not report the result inline

[untouch]

Fixes the VoP handling reported in #220.

Summary

Banks report Verification of Payee results in three different shapes. python-fints
currently recognises only one of them, so on the other two every transfer to a
third-party payee fails — with 3945 Freigabe ohne VOP-Bestätigung nicht möglich
— and can never be executed.

Bank	Where the VoP result appears	Before	After
Sparkasse	inline in vop_single_result	works	unchanged
Atruvia (Volksbank, GLS, VR)	asynchronous, behind a polling_id	always 3945	executes
Commerzbank	only inside payment_status_report	always 3945	executes

All three verified against real bank dialogs.

The three cases

1. Asynchronous result (Atruvia) — HIVPP carries neither vop_id nor
vop_single_result, only a polling_id and wait_for_seconds, accompanied by 3905
("no challenge created") and 3040 with a touchdown point. The client has to ask
again. It never did.

2. 3945 attached elsewhere (Commerzbank) — the existing check looked for the
code only in responses tied to the TAN segment:

'3945' in [res.code for res in response.responses(tan_seg)]

Some banks attach it to a different segment, so the condition never matched.

3. Result only in the status report (Commerzbank) — this bank omits
vop_single_result entirely and reports the outcome solely inside
payment_status_report, a pain.002 document:

HIVPP1(
    vop_id                = b'...',
    vop_id_valid_until    = ...,
    payment_status_report = <pain.002 with GrpSts RCVC>,
    manual_authorization_notice = '...'
)
HITAN6(challenge = 'Dies ist Ihre photoTAN Challenge.')

With vop_single_result absent, result_code is None and neither existing
branch can match — regardless of how widely 3945 is searched. No NeedVOPResponse
is produced, HKVPA is never sent, and the order is rejected after the TAN.

Changes

• _find_vop_aufsetzpunkt() — reads the touchdown point from HIRMS code 3040.
• _poll_vop_result() — re-sends HKVPP with polling_id and aufsetzpunkt
  until a result arrives. Both are mandatory; sending only one yields 9210
  (independently confirmed by two reporters in VoP: asynchronous result (polling / Aufsetzpunkt) not handled — transfers fail with 3905/3945 at Atruvia banks (GLS/VR) #220).
• 3945 is now looked for across all HIRMG/HIRMS segments.
• A present vop_id together with a payment_status_report now yields a
  NeedVOPResponse, covering banks that do not fill vop_single_result.

Two design decisions worth review:

Termination on data, not on a response code. The polling loop stops when vop_id
or payment_status_report appears. Depending on the server release, Atruvia finishes
with either 3090 or 0020/0025 — both are reported in #220 — so waiting for one
specific code hangs on the other variant.

Timeout raises instead of falling through. Without a result there is nothing to
approve and the order was not executed. Falling through would hand the caller a
TransactionResponse carrying only warnings, which reads like success — note that
_RESPONSE_STATUS_MAPPING maps 3945 to WARNING, not ERROR.

Why inline banks keep working

Each new branch is guarded by a condition that inline banks cannot satisfy:

• polling requires polling_id present and vop_id absent,
• the status-report branch requires result_code to be None.

For a bank that fills vop_single_result, both are false and execution continues into
the unchanged code — including the 0030/3955 TAN detection.

That distinction matters. As @payne1979 notes in #220, Sparkassen answer inline, fire
the pushTAN in step 1, and reject a separately sent HKVPA with 9010 — "Any fix
that assumes one of the two will break the other."

Measured, not assumed. A transfer through a Hamburger Sparkasse account after
these changes produced:

3091 VOP-Ausführungsauftrag nicht benötigt.
0010 Der Auftrag wurde entgegengenommen.
3076 Starke Kundenauthentifizierung nicht notwendig.

with no polling log line at all — the new code was never entered.

Verification

Berliner Volksbank (BLZ 10090000, Atruvia). Polled result on the first attempt:

3945 Freigabe ohne VOP-Bestätigung nicht möglich
-> VoP polling attempt 1 (polling_id=b'<uuid>', aufsetzpunkt='staticscrollref', wait=2s)
-> 0025 Keine Namensabweichung.
-> 0020 Ausführungsbestätigung nach Namensabgleich erhalten.
-> 0020 *SEPA-Einzelüberweisung erfolgreich

Commerzbank (BLZ 10080000). Previously 3945 on every attempt; now:

0010 Auftrag entgegengenommen. Ausführung erfolgt vorbehaltlich positiver Disposition.

Transfer confirmed in online banking the next morning.

Hamburger Sparkasse. Unchanged, see above.

Scope and limitations

• pain.002 is passed through untouched, not parsed. Callers receive the HIVPP and
  can inspect the report before approving — which is the point of VoP.
• No changes outside the VoP path; security.py and formals.py are untouched.

Relation to #211

#211 targets the same area and was a useful starting point — credit to @ArlindNocaj
for the polling idea. This PR differs in three ways: it loops with a timeout instead
of polling once, it selects branches by flow shape rather than by vop_id alone
(which keeps the inline path reachable), and it stays inside the VoP flow.

[untouch]

@raphaelm — I've completed the half of the verification that was missing when I opened this,
since "does it break the banks that already work?" is the obvious question for a change in
this area.

A transfer through a Hamburger Sparkasse account (inline VoP) on the patched version:

3091 VOP-Ausführungsauftrag nicht benötigt.
0010 Der Auftrag wurde entgegengenommen.
3076 Starke Kundenauthentifizierung nicht notwendig.

No polling log line was emitted at all, so the new branch was never entered and the transfer
behaved exactly as before. That is the case @payne1979 warned about in #220 — the inline
banks that fire the pushTAN in step 1 and reject a separate HKVPA with 9010.

The branch is selected by flow type (polling_id present and vop_id absent) rather than
by vop_id alone, which is what keeps that path reachable. Description updated with both
verifications side by side.

One observation from the same run, unrelated to this PR but possibly useful: that successful
Sparkasse transfer reported no 0020 — only 0010. Anything downstream that treats
0020 as the success marker would misread it as a failure.

Happy to adjust anything, split it up, or add tests if that helps.