fix(com): raise serial timeout 800ms -> 3000ms and make it configurable per address

[shizoxy]

Problem

Slow fiscal devices pause longer than 800ms between SYN (0x16) bytes while committing a receipt to fiscal memory on close. With the hardcoded 800ms ReadTimeout/WriteTimeout in ComTransport, the read loop times out, ParseResponse raises E107 "no response", and the ISL driver subsequently aborts the receipt — the device prints АНУЛИРАН БОН (cancelled receipt) even though the receipt may already be recorded in fiscal memory.

We reproduced this in production with a Daisy PerfectS (firmware ONL01AZ_EUR-1.0BG) on bg.dy.isl.com://COM5:

• Frequent Timeout occured while writing to com port 'COM5' immediately after port open (35 occurrences in a single day's log)
• Receipt close (0x38 / 0x82) returning SYN repeatedly, then timing out at 800ms; the delayed response later shows the receipt WAS committed (receipt number allocated, amount recorded), but the caller already received ok:false / E107
• This leads POS software to retry with the same or next USN, producing duplicate/ambiguous fiscal records — a compliance problem under Наредба Н-18

Fix

1. DefaultTimeout raised 800ms → 3000ms. The keep-alive/idle close timer already uses 3000ms, so an idle open port is disposed on the same schedule as before; normal responses still return in milliseconds — only genuinely slow devices benefit.
2. The COM address now optionally carries a per-device timeout: <Com>[:<Speed>[:<TimeoutMs>]], e.g. com://COM5:115200:5000. Fully backward compatible — existing COM5 / COM5:115200 addresses behave as before (with the new default).

Testing

• Built and deployed to the affected salon (Daisy PerfectS, Windows x64 self-contained): E107/aborted receipts no longer occur under the same load
• Existing devices on default addresses unaffected

Happy to adjust the default value or the address syntax if you prefer a different approach (e.g. appsettings-based timeout).

[p-kostov]

Thanks for the detailed write-up - the underlying problem is real and worth solving. However, I'm closing this PR as-is; a few points need to be sorted out first, ideally in an issue:

• Configurable timeout via the address is a good direction, but needs discussion. Before code, let's agree on the approach- a colon-suffix on the Uri (COM5:115200:5000) vs a structured per-printer field in appsettings.json - and keep the transport contract clean.

• Changing the library-wide default 800 -> 3000 isn't acceptable for a single device. It affects every device/manufacturer, and it slows auto-detection substantially (> 3.5 times per unresponsive COM port), which on machines with many COM ports can blow the 30s detection budget and cause real printers to be missed.

• No measurements provided. Please share the actual observed pause for the Daisy Perfect S. 3 sec is a very long default, and picking it without data is a guess - the configured value should be the measured one.

• Out-of-scope changes. The README "fork" banner, the .gitignore build-artifact entries, and the FashionPoint patch: code comments are fork-specific and don't belong in an upstream PR.

• Docs and formatting don't follow the project's conventions.

Please open an issue so we can align on the design. Thanks for reporting it.

[wqweto]

Btw, it makes a lot of sense for auto-detection timeout to be decoupled from command response timeout. Apparently 800 ms (which is almost double 500 ms what Daisy+Datecs recommend) timeout between device responses does not correspond to reality while a much smaller timeout (less than 50 ms) for auto-detection would suffice is most cases. Besides failing auto-detection is not like failing critical close receipt command i.e. it has some merrit to be faster in general.

Just my $.02