Savestate: don't let stale HLE helper threads mutate restored kernel state

[Arkadyzja]

The bug

On savestate load, two sites destroy a pre-load host object that owns an HLEHelperThread without calling Forget() first. ~HLEHelperThread then runs __KernelDeleteThread() and kernelMemory.Free() using a thread id and entry-block address from before the load, against the freshly restored kernel state:

• sceUtility: Do(p, accessThread) — DoClass deletes the stale host object before recreating it from the stream.
• scePsmf: Do(p, psmfPlayerMap) — the map serializer deletes every existing PsmfPlayer, and ~PsmfPlayer -> AbortFinish() does a raw delete finishThread.

When the stale id/block happens to be absent from the restored state, this only produces error spam (__KernelDeleteThread: thread ... does not exist, BlockAllocator: invalid free) — annoying but harmless. When the id or block has been recycled by the restored state, a live thread is terminated or a live allocation is freed, silently corrupting the state that was just loaded. Easiest to hit by loading a state while a savedata operation or PSMF player is active in the current session.

The fix

__IoDoState and __PsmfShutdown already handle this correctly by calling Forget() before deletion (which detaches the host wrapper from the kernel-side objects — those belong to the serialized state, not to the wrapper). This PR applies the same pattern to the two remaining sites:

• sceUtility.cpp: Forget() + delete the stale accessThread before Do(p, accessThread) deserializes the replacement.
• scePsmf.cpp: before Do(p, psmfPlayerMap) on MODE_READ, walk the existing map and Forget() each player's finishThread.

Risk

Load-path only; strictly removes writes to restored kernel state. Worst-case behavior change: a kernel-side thread record that was previously (incorrectly) freed is now left to the restored state to manage — i.e., exactly what the serializer intends.