[ET-VK] Fix staging buffer allocation to check all memory types for HOST_CACHED

[SS-JIA]

Stack from ghstack (oldest at bottom):

• [ET-VK][conv2d_dw] Extract depthwise dispatch into Conv2dDW.cpp with device-based tile selection #18293
• [ET-VK][conv2d] Re-implement pointwise conv2d with tiled compute and blocked weight packing #18292
• -> [ET-VK] Fix staging buffer allocation to check all memory types for HOST_CACHED #18291

test_host_cached_available() only checked memoryTypes[0] to determine if
HOST_CACHED memory was available. On Pixel devices, memoryTypes[0] is
DEVICE_LOCAL without HOST_CACHED, so the function incorrectly returned
SEQUENTIAL_WRITE_BIT. This caused DEVICE_TO_HOST staging buffers to be
allocated in write-combining (uncached) memory, making CPU reads during
COPY_OUTPUTS ~170x slower than necessary (~40ms vs ~237us on S24).

The fix iterates over all memory types to correctly detect HOST_CACHED support.

On-device profiling of edgetam_first_frame_fp16_vulkan.pte confirms the fix:

• Pixel 8 Pro COPY_OUTPUTS: 40ms -> 6.3ms (-84%)
• Pixel 9 Pro XL COPY_OUTPUTS: 40ms -> 2.5ms (-94%)
• Pixel 8 Pro Method::execute: 492ms -> 464ms (-5.7%)
• Pixel 9 Pro XL Method::execute: 445ms -> 411ms (-7.6%)

Differential Revision: D97058156

[pytorch-bot]

🔗 Helpful Links

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

• 📄 Preview Python docs built from this PR

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

⏳ 1 Pending, 2 Unrelated Failures

As of commit c4106b4 with merge base ed57040 ():

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.