[ET-VK] Fix pack_fp_linear_weight for devices without VK_KHR_16bit_storage

[SS-JIA]

Stack from ghstack (oldest at bottom):

• -> [ET-VK] Fix pack_fp_linear_weight for devices without VK_KHR_16bit_storage #18642

The pack_fp_linear_weight prepack shader crashes on devices that lack
VK_KHR_16bit_storage support because the half-precision variant reads from a
float16_t[] staging buffer, which requires that extension.

This applies the same two-dtype pattern used by nchw_to_image and
conv2d_dw_prepack_weights: a new BUF_DTYPE shader parameter allows the
staging buffer to use float32 ([half, float] combo) while the packed output
remains half-precision. The runtime selects the correct variant via
get_staging_dtype_for(), which returns kFloat when the device lacks fp16
buffer support.

All three call sites that construct the pack_fp_linear_weight shader name
(Linear.cpp, Conv1dPW.cpp, Conv2dPW.cpp) are updated to append the staging
dtype suffix.

Authored with Claude.

Differential Revision: D99133993

[pytorch-bot]

🔗 Helpful Links

🧪 See artifacts and rendered test results at hud.pytorch.org/pr/pytorch/executorch/18642

• 📄 Preview Python docs built from this PR

Note: Links to docs will display an error until the docs builds have been completed.

❌ 1 New Failure, 1 Pending, 2 Unrelated Failures

As of commit 44b193b with merge base ad235f8 ():

NEW FAILURE - The following job has failed:

• Build Presets / apple (ios) / build (gh)
  The process '/opt/homebrew/bin/git' failed with exit code 128

BROKEN TRUNK - The following jobs failed but were present on the merge base:

👉 Rebase onto the `viable/strict` branch to avoid these failures

• pull / unittest / windows / windows-job (gh) (trunk failure)
  ##[error]The operation was canceled.
• pull / unittest-editable / windows / windows-job (gh) (trunk failure)
  ##[error]The operation was canceled.

This comment was automatically generated by Dr. CI and updates every 15 minutes.

[github-actions]

This PR needs a release notes: label

If your change should be included in the release notes (i.e. would users of this library care about this change?), please use a label starting with release notes:. This helps us keep track and include your important work in the next release notes.

To add a label, you can comment to pytorchbot, for example
@pytorchbot label "release notes: none"

For more information, see
https://github.com/pytorch/pytorch/wiki/PyTorch-AutoLabel-Bot#why-categorize-for-release-notes-and-how-does-it-work.