Fix dangling pointer crash in PacketReader(byte[], bool)

[kamronbatman]

The bug

PacketReader(byte[] buff, bool dyn) in Razor/Network/Packet.cs stored a byte* past the lifetime of its fixed block:

public PacketReader(byte[] buff, bool dyn)
{
    fixed (byte* p = buff)
        m_Data = p;       // pinned ONLY for this statement
    m_Length = buff.Length;
    ...
}

The instant the fixed block exits, buff is unpinned and may be relocated by the GC. m_Data becomes a dangling pointer; every subsequent ReadByte dereferences whatever now lives at the old address — usually still-valid heap memory (silent), sometimes garbage from another allocation, sometimes an unmapped page.

The reliable production trigger is GetCompressedReader → CompressedGump. The handler allocates new string[numStrings] between constructing the inner reader and the first pComp.ReadInt16(), opening a Gen0 collection window before any read happens.

In .NET Framework 4+, AccessViolationException is a Corrupted State Exception. Razor's app.config doesn't enable <legacyCorruptedStateExceptionsPolicy> and no method carries [HandleProcessCorruptedStateExceptions], so the AVE escapes both catch blocks (CompressedGump's and ProcessViewers's) and the process is terminated. This matches the reported production stack trace verbatim:

at Assistant.PacketReader.ReadByte()
at Assistant.PacketReader.ReadInt16()
at Assistant.PacketHandlers.CompressedGump(...)
at Assistant.PacketHandler.ProcessViewers(...)
at Assistant.PacketHandler.OnServerPacket(...)
at Assistant.ClassicUOClient.OnRecv(...)

Empirical proof

A standalone repro built two readers — the current buggy ctor and a GCHandle.Pinned variant — fragmented the LOH with bracketing 100KB allocations, dropped the holes, forced a compacting Gen2 GC, then read every byte. 30 runs each on x64 Server GC, .NET 4.7.2:

Scenario	Buff relocated	Lucky-correct reads	Garbage reads	AccessViolationException
Buggy (current master)	30/30	28	1	1
Fixed (this PR)	0/30 (pinned)	30	0	0

The buggy run produced the exact AccessViolationException at ReadByte shown in the production crash. The fixed reader couldn't be relocated at all (GCHandle.Pinned is what it says on the tin) and every byte read came back correct. Note the bug is observable in 2/30 runs as garbage or AVE; the other 28 are "lucky" — the freed memory at the stale address still happened to contain the original bytes. This explains why crashes feel rare in production despite the bug firing on every CompressedGump.

The fix

Replace the leaked fixed pointer with a GCHandle.Alloc(buff, GCHandleType.Pinned) taken in the ctor and freed in a finalizer. The byte* overload calls GC.SuppressFinalize(this) since the caller owns the pin in that path.

public PacketReader(byte[] buff, bool dyn)
{
    m_Handle = GCHandle.Alloc(buff, GCHandleType.Pinned);
    m_Data = (byte*)m_Handle.AddrOfPinnedObject();
    m_Length = buff.Length;
    m_Pos = 0;
    m_Dyn = dyn;
}

~PacketReader()
{
    if (m_Handle.IsAllocated)
        m_Handle.Free();
}

The pin lasts at most one GC cycle past the reader's last reachable use (until the finalizer runs), which is well under a millisecond in practice. No callers need to change.