fix(recording): reschedule packet send recording onto server thread

[DriftN2Forty]

Summary

• reschedule block break packet recording onto the server thread before any Bukkit lookups or recording-state mutation
• capture only the packet fields needed from the PacketEvents callback so the Netty-side work stays narrow
• add regression coverage for the handoff path and document the fix in the changelog

Problem

Issue #43 reported a Netty packet-send thread blocked in HashMap.put while BetterReplay was recording block break animations.

Before this change, the PacketEvents send listener handled more than packet decoding. It also performed Bukkit lookups and mutated shared recording state directly from the packet callback. That meant a Netty thread could touch:

• the block break dedup map
• tracked player and entity state
• the timeline builder and append-log path

That is the wrong thread boundary for both Bukkit access and BetterReplay's recording session state.

Fix

The packet listener now copies the minimal block break animation data it needs immediately, then reschedules the actual recording work onto the server thread through FoliaLib. Bukkit lookups, dedup mutation, and timeline event emission all happen on the server thread again.

This keeps the packet callback small and removes the cross-thread mutation hazard that was behind issue #43.

Validation

• runTests passed for RecordingPacketHandlerTest
• the full test suite passed with 481 tests green

Refs #43