fix(agc): validate reset queue cache packets

[MarcZX10]

What

Refs #1581. Accept the measured whole-range ACQUIRE_MEM packet over a 48-bit address range and the measured EVENT_WRITE type 56 cache-flush timestamp packet. These are the unimplemented packet groups for reset op bits 0x040 and 0x200 described in #1581, and unblock those groups in #1629. The 0x400 group remains unsupported.

The packet values and fields covered by the new cases come from the PS5 firmware 13.60 command-buffer measurement in #1581. Validation still rejects fields outside the 48-bit range, overflowing spans, null or misaligned timestamp addresses, and invalid event indices.

Tested

Linux, GCC 12.2, Release: built agc_driver_pm4_tests; ctest -R '^agc_driver_pm4$' passed. Added acceptance checks for the measured packets and rejection checks for invalid ranges, addresses, and indices. No PS5 hardware run was performed.

Checklist

• Based on current main; no other open PR implements the same validation
• One topic per PR; follow-ups go in a new PR
• No comments in code except technical debt
• Unimplemented paths throw; no new silent stubs
• No notes, investigation files or images added to the repository
• No new third-party code
• Generic behaviour, not specific to one title
• Depends on: none
• AI-assisted: yes

[github-actions]

Other open pull requests touch the same code. Merging one will break the other, or both implement the same thing. If this one builds on them, list them in Depends on.

Pull request	Conflicting files (lines on main)	Same exports	Same new files
#1917	core/libs/prx/libSceAgcDriver/Execution/src/Pm4.cpp L366, L368-370 core/libs/prx/libSceAgcDriver/tests/Pm4.cpp L566-567, L571

[MarcZX10]

Closing after a full diff review. The 48-bit ACQUIRE_MEM validation and tests in this PR are already implemented by #1917. I also rechecked the measured EVENT_WRITE 0x38 packet: PAL identifies 0x38 as PIXEL_PIPE_STAT_CONTROL (gfx9CmdUtil.cpp), not a cache-flush timestamp. This PR only validates the packet and does not model its pixel-pipe statistics effect, so accepting it would claim behavior the driver does not implement. I removed that case in local follow-up commit d341201e; no distinct, correctly implemented change remains here. The measured event needs a behaviorally grounded implementation before it can be accepted.