fix(imx296): correct fast-trigger frame delivery and PWM recovery

[OKayJH]

Summary

• fix IMX296 fast-trigger ROI transitions delivering the previous frame
• expose fast-trigger state to RKISP and complete the current V39 frame after the last observable output line
• delay vb2 completion long enough for tail DMA to finish
• reset ROI geometry explicitly and drain invalid free-run frames after ROI changes
• preserve the firmware PWM base period so shorter exposures shrink the trigger period again
• add a tracked YYYYMMDDNN DLCVCAM build identifier, visible on the build host and through uname -v on the board

Problem

After changing ROI in fast-trigger mode, the first captured result could correspond to frame N-1. Separately, a long exposure enlarged the PWM period, but returning to a short exposure reused that enlarged runtime period as the permanent baseline. The maximum trigger rate then remained around 20 fps instead of recovering to around 50 fps until reboot.

The previous release build number was supplied manually through KBUILD_BUILD_VERSION, so the repository and delivered board could disagree. The new DLCVCAM_BUILD_VERSION file uses YYYYMMDDNN (currently 2026072201) without changing uname -r or the kernel module directory.

Validation

• scripts/checkpatch.pl --strict: frame/PWM commits passed with 0 errors and 0 warnings; build-version commit has 0 errors and only the generic new-file MAINTAINERS warning
• targeted ARM64 build passed for imx296.o, capture.o, capture_v39.o, and rkisp.o
• full ARM64 kernel build completed successfully
• date-version incremental ARM64 Image dtbs modules build completed successfully
• generated Image contains 6.1.99-rk3576 ... #2026072201 SMP
• make -s dlcvcam-build-version works for source and O= builds; command-line override remains supported
• legacy .version remains unchanged during release builds
• git diff --check origin/rk3576..HEAD passed