Add credit card transaction retrieval (DKKKU)

[jwtue]

Credit card accounts have no IBAN, so they are missing from HKSPA and their transactions cannot be
fetched with HKKAZ or HKCAZ. The only route is DKKKU, a business transaction defined by the
Deutsche Kreditwirtschaft rather than by the FinTS specification, which the Sparkassen-Finanzgruppe
offers among others.

$getCards = \Fhp\Action\GetCreditCardAccounts::create();
$fints->execute($getCards);

$getTransactions = \Fhp\Action\GetCreditCardStatement::create($getCards->getAccounts()[0], $from, $to);
$fints->execute($getTransactions);

Changes:

• Segments DKKKU / DIKKU / DIKKUS v2 in Fhp\Segment\KKU
• GetCreditCardAccounts, which takes the accounts from the HIUPD segments received during login
  and therefore needs no request to the bank at all
• GetCreditCardStatement, paginateable
• A dedicated result model, because credit card records are flat and carry fields MT940 does not have
• Accessors on HIUPD for account, account type, holder name, product name and currency
• Sample and README section

On the segment definitions: there is no public specification for DKKKU. The starting point was
AqBanking's declarative definition,
which turned out to be wrong in four places. All four were found by comparing against real responses
and are documented in the code:

1. The record ends with a merchant category code that AqBanking does not list, so the segment failed
   to parse at all. It is absent for bookings without a merchant, hence optional.
2. value2 is not a duplicate of value, but the amount in the currency the merchant charged.
3. unknown3 is not the constant "1,", but the exchange rate — e.g. 34.99 USD * 0.86941 = 30.42 EUR.
4. The request has a field for the number of entries, which the DIKKUS parameters announce a flag
   for. Without it the bank rejects a paginated follow-up with 9110 Unbekannter Aufbau.

Points 2 to 4 only surface on foreign currency transactions or when paginating, which is presumably
why they went unnoticed.

Tested against BW-Bank/LBBW (60050101), which advertises DIKKUS:...:2. A real query returned
~470 transactions including foreign currency bookings and settlement credits. The unit test fixtures
mirror those responses with all account numbers, names, merchants and amounts replaced.

Limitations: the corrected position of the pagination token could not be confirmed — the bank
paginated once and then not again on any later attempt with the same query. The first request of a
query is unaffected either way, since the field stays empty there. Only DIKKUS v2 at a single
institute was exercised. Also note that querying beyond the retention window announced in DIKKUS
is not rejected but answered inconsistently, so callers should stay within it.

Developed with the assistance of Claude Code. Every claim about the segment layout above was verified
against real bank responses rather than taken from the model.

[Philipp91]

Most other segment classes and also some actions have links to the respective specification documents. Is there something similar here, like some PDF you could link to?

[Philipp91]

This is a good reference.

[jwtue]

Most other segment classes and also some actions have links to the respective specification documents. Is there something similar here, like some PDF you could link to?

there is no public document for DKKKU — it is an association-specific transaction of the Sparkassen-Finanzgruppe, and its specification is only handed out by SIZ under NDA. AqBanking's declarative definition is the only public description at implementation level, which is what the segments link. I pushed 703aafc earlier to state that on the segments themselves rather than leave the absence unexplained.

[Philipp91]

to state that on the segments themselves rather than leave the absence unexplained.

That's great.