Implement receipt lottery handling on the Custom RT Server

[danielscainifiskaltrust]

Context

The CustomRTServer SCU did not handle the receipt lottery code:
RTCodiceLotteria was hardcoded to an empty string in ProcessFiscalDocumentAsync,
so the code sent by the POS in ftReceiptCaseData was silently dropped
(unlike CustomRTPrinter and Epson, which already handle it).

Changes

scu-it

• CustomRTServerMapping: when present, the codicelotteria is read via GetLotteryData()
  and embedded as lottery_client_code inside fiscalData (using DocumentDataLottery).
  QR/SHA is still computed over the serialized string → signature stays consistent.
• CustomRTServerSCU: reads the code back from the document and populates RTCodiceLotteria
  (→ <rt-lottery-id> signature); passes an isLottery flag to the queue.
• CustomRTServerClient: InsertFiscalDocumentLotteryAsync now sends the same CommercialDocument
  as the normal flow to /insertFiscalDocumentLottery.php (same payload → same SHA/HMAC).
• CustomRTServerCommunicationQueue: lottery receipts are routed to the dedicated endpoint
  in both sync and async modes (disk cache uses a dedicated filename suffix);
  send loops (background + daily closing) and counters updated accordingly.
• SignatureFactory: the <rt-lottery-id> signature was moved to the end of the array,
  so it is always last even when customer-id/reference signatures are present.

queue

• No production change: the [www.fiskaltrust.it] footer already included
  Codice Lotteria: <code> by reading the RTLotteryID signature. Now that CustomRTServer
  emits it, the footer is populated automatically. Added coverage tests only.

Signature output

For a receipt carrying a lottery code, the response contains:

• <rt-lottery-id> → ftSignatureType 0x4954200000000015, ftSignatureFormat 0x1, Data = <code>
• [www.fiskaltrust.it] footer (ftSignatureType 0x4954200000000001) with a Codice Lotteria: <code> line

Testing

• scu-it unit tests: lottery_client_code embedding in fiscalData, signature on/off,
  routing of lottery documents to the dedicated endpoint.
• queue unit tests: footer with / without Codice Lotteria.
• Live verification against a test RT server: document accepted (responseCode 0, fiscalDocId assigned)
  on both /insertFiscalDocument2.php (embed) and /insertFiscalDocumentLottery.php,
  paid by electronic payment (required for the lottery to be valid).

Notes

• The only remaining failing test is CustomRTMappingTests.GenerateTaxDataForReceiptRequest_Should_Map_Correctly,
  which already fails on main and is unrelated to this PR.
• InsertFiscalDocumentArrayLotteryAsync and the FDocumentLottery model are now unused
  [removed in this PR / to be removed separately — pick one].

Issue
#697

[github-actions]

✅ CLA Signed

All contributors have signed the CLA. Thank you!

[github-actions]

SCU.IT Test Results

  8 files   8 suites   2s ⏱️
 58 tests 22 ✅ 36 💤 0 ❌
116 runs  44 ✅ 72 💤 0 ❌

Results for commit 721bfb2.

[github-actions]

Queue Test Results

   43 files     43 suites   3m 34s ⏱️
  752 tests   749 ✅ 3 💤 0 ❌
1 880 runs  1 874 ✅ 6 💤 0 ❌

Results for commit 721bfb2.

[danielscainifiskaltrust]

I have read the CLA Document and I hereby sign the CLA