Off-render-thread detection in the OpenGL backend depends on the route taken

RenderSystem.assertOnRenderThread guards 74 of the 82 static methods in GlStateManager, but not _texImage2D, either overload of _texSubImage2D, _glBindFramebuffer, _glBlitFrameBuffer, _getTexLevelParameter, _viewport or getFrameBuffer, the texture upload calls among them. Around a hundred further GL33C calls elsewhere in the backend bypass GlStateManager altogether, so whether a call made from the wrong thread is caught depends on which entry point the path touches first rather than on the call being wrong.

writeToTexture shows both outcomes in one method. On a plain 2D texture it reaches _bindTexture, which asserts and throws before anything is issued. On a cubemap it takes the other branch and calls GL33C.glBindTexture directly, so a real GL call goes out on the wrong thread, and only the following _pixelStore raises. When a route with no guard is taken from the wrong thread, no exception is raised and the behaviour is undefined: the GL context belongs to the render thread, so the call may be silently dropped, or it may reach a context that is concurrently in use and leave the state machine in an inconsistent state. Either way the effect surfaces later as incorrect rendering that is hard to trace back and may not reproduce consistently.

Placing the check at the point where the backend is entered, rather than on individual state manager methods, would make the outcome depend on the thread instead of on the route, and would cover the direct GL33C calls that no per-method guard can reach.