fix incorrect MTP xact_len calculation

[RigoLigoRLC]

Describe the PR

Fixes the calculation of remaining bytes to transfer in MTP device class.

The original code casts the result of subtraction into uint16_t before taking the minimum, which will break all transfers with more than 65535 bytes. Only (filesize & 0xFFFF) bytes can be transferred before the transfer comes to a halt. This PR has deferred the cast to uint16_t after calculating the transfer size in uint32_t domain.

This bug is discovered when I'm testing MTP Device with an LittleFS on SPI flash as the backing store, with about 11MiB of free space I copied a lot more data than what was available in the examples and it immediately revealed this issue. After applying this change, the issue was resolved and I can copy megabytes of files into the responder device.

And file hashes are compared. The file was copied to the responder device on macOS and is copied out from responder device on Windows.

Additional context

The test project can be found at https://github.com/RigoLigoRLC/esp32s3-tusb-mtp . It uses my own fork of espressif/tinyusb with MTP implementation applied on top of v0.18 branch.

[Copilot]

Pull Request Overview

This PR fixes a bug in the MTP device class where transfers larger than 65535 bytes would fail due to incorrect type casting in the transaction length calculation. The issue occurred because the subtraction result was cast to uint16_t before taking the minimum, causing overflow for large file transfers.

• Fixed the order of operations in xact_len calculation to prevent integer overflow
• Changed from tu_min16() with premature uint16_t cast to tu_min32() with post-calculation cast

[HiFiPhile]

Thank you !