uds: don't send consecutive frames past the end of the payload

[singhharsh1708]

When an ECU's flow control frame asks for a bigger block size than the payload has left, IsoTpMessage keeps emitting consecutive frames past the end of tx_dat. The slice is empty and ljust pads it, so frames carrying no payload go out on the bus, each one costing another separation time delay.

An 8 byte request answered with flow control 30 08 14 sends eight consecutive frames on master: 2117180000000000, then 2200000000000000 through 2800000000000000. Only the first carries payload. With this change it sends that one frame. ISO 15765-2 section 9.6.5.3 says only the last block of a transfer may have fewer than BS frames, so stopping when the payload runs out is the specified behaviour. Multi-block transfers are unchanged, 25 and 30 bytes at block size 2 still send 2 frames per block.

Scope is small and worth stating: opendbc's own firmware queries never reach this path, since all 127 requests in FW_QUERY_CONFIGS are 7 bytes or shorter and take the single frame path. This affects callers using UdsClient or IsoTpMessage directly with a request of 8 bytes or more.

Clamping end to tx_len is the fix pd0wm proposed in the issue. There is no test file for IsoTpMessage today, happy to add one if you want the behaviour pinned.

Fixes #1682

[github-actions]

Car behavior report

Replays driving segments through this PR and compares the behavior to master.
Please review any changes carefully to ensure they are expected.

✅ No changes detected

[github-actions]

Thanks for contributing to opendbc! In order for us to review your PR as quickly as possible, check the following:

• Convert your PR to a draft unless it's ready to review
• Read the contributing docs
• Before marking as "ready for review", ensure:
  • the goal is clearly stated in the description
  • all the tests are passing
  • include a route or your device' dongle ID if relevant