fix(qwen3_vl): align video timestamp token placement with transformers

[kcz358]

Summary

Fixes #132

• Timestamp token ordering: The Qwen3 VL processor was placing timestamp tokens after <|vision_start|>, producing <|vision_start|><timestamp><video_pads><|vision_end|>. The canonical Qwen3VLProcessor in transformers places timestamps before <|vision_start|>, producing <timestamp><|vision_start|><video_pads><|vision_end|>. This PR aligns lmms-engine with the upstream behavior.
• temporal_patch_size vs merge_size: Changed _calculate_timestamps to use temporal_patch_size instead of merge_size, matching the transformers implementation. Both default to 2 so this was a silent bug, but using the semantically correct parameter prevents issues if the values ever diverge.
• Simplified the per-frame expansion logic from a 3-case if/elif/else (first/middle/last frame) into a single uniform pattern, since all frames now follow the same structure.

[kcz358]

I do not think this fully fixes #132.

This PR does fix the timestamp-token ordering issue and aligns qwen3_vl_processor.py with upstream transformers:
<timestamp><|vision_start|><video_tokens><|vision_end|>

It also correctly switches the timestamp calculation to use temporal_patch_size, which matches the upstream processor behavior.

However, issue #132 also reports a separate dataset-side problem: the Qwen3-VL dataset resize / patch-size handling appears to be inconsistent (the issue mentions missing patch size 16 alignment). This PR only changes src/lmms_engine/datasets/processor/qwen3_vl_processor.py and does not touch src/lmms_engine/datasets/iterable/qwen3_vl_iterable_dataset.py, so that part still seems unresolved.

So I think this PR fixes the first part of #132, but Fixes #132 is probably too strong unless the dataset-side issue is handled elsewhere.