fix(interp): use 1/scale_factor coordinate scale for bilinear/bicubic resize

[Lfan-ke]

Interp's linear_coeffs/cubic_coeffs always derive the sampling scale from w / outw, but when resizing by a scale factor (no explicit output size) the coordinate scale should be 1 / scale_factor, matching PyTorch. #3555 fixed this for nearest; bilinear/bicubic were missed.

For integer scale factors the two are equal, so this only affects non-integer factors, e.g. F.interpolate(x, scale_factor=1.5, mode='bilinear').

Fix: thread the scale-factor-aware scale (the same expression already used on the nearest path) into linear_coeffs/cubic_coeffs across all backends. The vulkan path drops the resize_type == 2 special-case so bilinear uses the same scale as nearest - the shader already applies the scale generically.

Verification: for a 5-wide input at scale_factor=1.5 (outw=7), bilinear output changes from 0, 0.5714, 1.2857, ... to 0, 0.5, 1.1667, 1.8333, 2.5, 3.1667, 3.8333, matching PyTorch's (dx+0.5)/1.5 - 0.5 mapping exactly. Verified locally on x86 (native) and aarch64 (cross-compiled + qemu) that each backend's output matches the corrected naive reference via test_interp.

Closes #6836

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 2e0281602a

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Preserve reference-size scaling for dynamic targets

When dynamic_target_size==1 without size_expr, the two-input Interp path gets the target size from reference_blob, but output_width stays 0. This new ternary therefore passes 1.0 / width_scale (usually 1) instead of the old w / outw, so dynamic bilinear/bicubic resizes such as 16→12 sample positions 0..11 rather than spanning the source. Treat dynamic targets like explicit sizes here and in the copied backend calls.

Useful? React with 👍 / 👎.

[chatgpt-codex-connector]

Update Vulkan bicubic coefficient scales

This updates the Vulkan nearest/bilinear constants to use 1 / width_scale and 1 / height_scale for scale-factor resizes, but resize_type==3 does not use these constants; the bicubic coefficient pipelines below still receive bottom_blob.w / outw and bottom_blob.h / outh. For non-integer scale-factor bicubic on Vulkan, GPU output remains on the old coordinate grid while the CPU backends now use the corrected scale.

Useful? React with 👍 / 👎.

[Lfan-ke]

Both real, fixed. Added dynamic_target_size to the target-size condition at every call site (naive + all backends, threaded through the interp_bf16s free functions), and gated the Vulkan bicubic constants[2] the same way. Independent check: a dynamic 16->12 resize now spans the source (0.167 ... 14.833, max err 0.0 vs the bug's 0 ... 11); test_interp passes, and scale-factor resizes still use 1/width_scale.