cuda: fix row stride in calculate_motion_score_kernel_16bpc (wrong scores for >8-bit input)

[BardieJoensen]

The CUDA motion feature extractor computes wrong scores for any input with bpc > 8.

In calculate_motion_score_kernel_16bpc the source rows are addressed like this:

blurred_y += filter_d[yf] * (reinterpret_cast<const uint16_t*>(src.data[0])
    + mirror(y-radius+yf, height) * src.stride[0])[mirror(x-radius+xf, width)];

src.stride[0] is in bytes, but the pointer arithmetic happens on a uint16_t*, so the row offset is doubled. Every row reads from row 2*y instead of y, and everything from height/2 down reads past the end of the plane. The 8bpc kernel just above does the same addressing correctly through a uint8_t*.

Whether this crashes or silently corrupts the result depends on what happens to be mapped after the allocation. On my setup (RTX 5060 Ti, driver 595.71.05, reproduced with CUDA 12.9 and 13.3 builds) it usually doesn't crash, which is probably why it hasn't been reported. On a 1080p 10-bit test pair, master @ 0f9912e:

	before (GPU)	after (GPU) = CPU --gpumask 0
vmaf mean	62.6037	63.5439
integer_motion2 mean	0.7869	1.5742
max per-frame vmaf diff	1.0769	0

compute-sanitizer attributes it deterministically:

========= Invalid __global__ read of size 2 bytes
=========     at calculate_motion_score_kernel_16bpc+0xf90
=========     by thread (0,14,0) in block (6,33,0)
=========     Access to 0x100120380bc is out of bounds
=========     and is 189 bytes after the nearest allocation at 0x10011c00000 of size 4423680 bytes

The numbers check out: the faulting thread is (x,y) = (96,542), whose first filter tap reads row 540. With the doubled stride that's byte offset 540 * 4096 * 2 = 4,423,680 — exactly the size of the 1080-row, 4096-byte-pitch source plane — plus 2 * (96-2) = 188 bytes of column offset.

Repro:

ffmpeg -f lavfi -i testsrc2=size=1920x1080:rate=24:duration=2 -pix_fmt yuv420p10le -strict -1 ref.y4m
ffmpeg -i ref.y4m -vf gblur=sigma=1.5 -pix_fmt yuv420p10le -strict -1 dist.y4m
vmaf -r ref.y4m -d dist.y4m -m version=vmaf_v0.6.1 -o gpu.json --json
vmaf -r ref.y4m -d dist.y4m -m version=vmaf_v0.6.1 -o cpu.json --json --gpumask 0
# per-frame vmaf / integer_motion2 differ between the two

An 8-bit pair produces identical GPU/CPU scores, so only >8bpc input is affected.

With this one-line change the GPU path matches --gpumask 0 exactly on both pairs and the sanitizer is clean.