perf(vu): reuse XGKICK packet storage between transfers

[GTTeancum]

Summary

Avoid clearing/copying the 64 KiB XGKICK packet buffer at every transfer launch. Reset only the transfer metadata in startXgkick; keep reset/initialization behavior unchanged.

progressXgkick writes each transferred qword before publishing the copied prefix, and a packet is submitted only after its complete declared length has been copied. Bytes beyond that prefix do not need initialization between transfers. The existing source-address, issue-cycle, and cycle-credit assignments remain unchanged.

With MSVC Release in the integration build, the old aggregate assignment produced a 64 KiB stack temporary, memset, and memcpy. Binary inspection confirms those bulk operations and the large stack frame disappear with this change.

Regression Coverage

A synthetic microprogram issues consecutive 4096-, 32-, and 80-byte IMAGE packets through the same storage. The test compares every submitted byte and exact packet lengths, checks completion cycles 511/514/523, and repeats with 4096/1/3/8/64-cycle execution budgets. No private game assets or generated game code are included.

Validation

• Based directly on upstream main 14b1e5c.
• Windows x64, Visual Studio 2022, Release: 426/426 tests pass with the new regression and original runtime, and 426/426 pass after the optimization.
• Separate X-Men Legends integration build: 139/139 VU-related tests and two recorded workloads remain exact at normal and 1/8/16/64-cycle slicing, including pending state, packet bytes, and cycles.
• Seven alternating uninstrumented comparisons in that integration build: original recording 2727.913 -> 2305.994 ms (15.47% reduction), broader recording 2106.688 -> 1734.131 ms (17.68% reduction), 7/7 wins each. These are recorded VU workloads, not an upstream benchmark suite or whole-game FPS claims.

No packet timing, rendering semantics, public API, or structure-layout change is intended.