GlCommandEncoder.copyTextureToTexture exposes render pipeline to GL_INVALID_OPERATION and undefined behavior due to missing format type validation

The com.mojang.blaze3d.opengl.GlCommandEncoder#copyTextureToTexture method contains a critical logical flaw. It allows mixing incompatible internal format types (e.g., Float vs Integer) which violates the OpenGL specification, leading to driver instability.

Steps to Reproduce (Code Analysis):

1. Inspect the source code for com.mojang.blaze3d.opengl.GlCommandEncoder.java.

2. Locate the method copyTextureToTexture.

3. Observe the validation logic: it checks source.getFormat().hasColorAspect(), but ignores the underlying data type (Signed/Unsigned Integer vs Fixed-point/Float).

4. Compare this logic against the OpenGL Specification for glBlitFramebuffer, which explicitly states that mixing these formats generates GL_INVALID_OPERATION.

Expected Result:
The method should validate that the source and destination textures share a compatible Internal Format Type (as required by OpenGL) before attempting the operation. It should throw an IllegalArgumentException if they are incompatible, protecting the render pipeline.

Actual Result:
The validation is missing. The engine proceeds to issue an invalid glBlitFramebuffer command.
This results in:

1. GL_INVALID_OPERATION errors generated by the driver.

2. Potential rendering corruption or driver crashes/timeouts on strict hardware/drivers.

3. The render pipeline enters an undefined state, only catching the error via _getError() after the damage is done.