fix(logging): prevent dropped frames in multi-device logs

[crazy0104]

Summary

• share one file transport across all selected devices instead of opening the same log file once per device
• route device messages into the shared writer while preserving channel filtering and close it only once
• keep BLF objects intact at container boundaries and serialize compression writes
• use the expected BLF padding convention in the reader and add multi-device regression coverage

Root cause

Each device logger invoked the file transport factory independently. With multiple CAN channels selected, this created multiple writers for the same ASC/BLF path. Since each writer opened the file for writing, they could truncate or overwrite one another, even though the per-device statistics remained correct.

BLF logging also sliced the uncompressed buffer at the container limit without respecting object boundaries, and compression jobs could finish out of order. The BLF reader additionally used an incompatible padding calculation, which could stop parsing at a container boundary.

Validation

• npx vitest --config vitest.config.ts run test/transport/deviceLog.test.ts test/replay/replay.spec.ts — 12 tests passed
• npm run typecheck
• generated a 5,000-frame, two-channel BLF and read all frames with python-can
• replayed the recorded BLF and confirmed both channels retained the complete 5,000-frame payload sequence

Fixes #417

[lmg0521]

请问上面的修复也能解决单通道记录的log丢帧的问题吗？我尝试使用一个通道记录数据，也会存在recv cnt和发送端一致，但是log中丢帧的情况

[crazy0104]

请问上面的修复也能解决单通道记录的log丢帧的问题吗？我尝试使用一个通道记录数据，也会存在recv cnt和发送端一致，但是log中丢帧的情况

这个PR优化了下多通道Log的相关实现，单通道应该也有改善，使用过程还是有问题可以单独提一个issue.。