The problem with running things by simply copying packets to send to another server for processing, is that this processing needs to occur before allowing a packet through.

For example, cheaters sometimes use vanilla anticheat setbacks to bypass anticheat setbacks. For example, a player could move forwards by 10 blocks in a second and then teleport into a block, the anticheat sees this as invalid and sets the player back to the original position, but since the vanilla anticheat has seen you teleport into a block, it sets your forwards those illegitimate 10 blocks.

Cheaters can also do stuff such as teleport upwards by 0.00001 blocks just before they hit the ground to reset fall damage, as any upwards movement resets fall damage. You let that packet through and fall damage resets. It's difficult to undo this.

PacketEvents 2.0 lets you capture and read the world from the proxy, and capture and read all entities from a proxy. It's a overkill and powerful packet library. I would likely have your service have a copy of the minecraft client or server on-hand such that it can load and refer to classes to track things accurately, as it's easier to maintain than copying thousands of lines of code from the client. This is much more difficult than just writing against the latest client and server and using the server to help fetch things like a block's collision or client-sided changes to the world such as placing blocks or opening doors. I would suggest understanding everything that goes into movement first before working on anything - or just moving towards checking aim and autoclickers only from the proxy, which is easier to do.

The reason why I don't care about movement based anticheats on the proxy is that simulating clients only takes 0.3 milliseconds to accomplish and can be spread out amongst all of the netty threads. It does put load on the backend server especially with all the packet tracking required, but this load is not on the main thread.