[Metal] Fix staging buffer overflow on large update_buffer uploads (#24643)

update_buffer payloads were appended into the single device-shared,
fixed-capacity (default 128 KiB) staging buffer. Its offset only resets
when all command buffers using it are destroyed, so an oversized host
upload chunked by the generic queue_emulated_update (e.g. a ~1 MiB
upload split into 64 KiB pieces, all recorded into one command buffer)
exhausts the region on the third chunk and fails with
RESOURCE_EXHAUSTED. This also forced bulk updates to compete with
dispatch argument buffers for the budget the 128 KiB constant was sized
for.

Keep the shared staging buffer as an opportunistic fast path for
payloads that fit, and spill to a dedicated shared-storage MTLBuffer
when one does not fit the remaining capacity. Dedicated buffers are
retained for the command buffer's lifetime (released in
command_buffer_reset, which runs only after the GPU completes via the
submission resource set) and used as the blit-copy source. This handles
arbitrary update sizes and counts without touching the driver-generic
queue_emulation chunking, matching how Vulkan and CUDA capture update
payloads per-command rather than in a shared fixed region.

Fixes the aligned16_mib sub-case of
CTS/CommandBufferCopyBufferTest.CopySizeAndAlignmentClasses/metal.

Signed-off-by: Alex Vasile
<48962821+Alex-Vasile@users.noreply.github.com>

Signed-off-by: Alex Vasile <48962821+Alex-Vasile@users.noreply.github.com>