Use move semantics

I am refactoring the resource manager to use move semantics so assets transfer ownership cheaply. Implement move constructor and move assignment for the Texture class so that GPU handles are transferred and the moved-from object is left in a safe, destructible state. Ensure no double-free of the GPU handle and that the move is noexcept where appropriate. Ladder L1

Before I change many resource types to be movable, make the change reviewer-friendly. List the class invariants that must hold after a move, mark which members should be nulled or reset, show where noexcept must be added for containers to perform moves, and flag code paths that rely on the old copy behavior. Ladder L2

I implemented a move constructor for Texture and then std::vector<Texture> began to throw or abort during push_back or reallocation. I suspect my move is not noexcept and containers fall back to copies. I cannot find which invariant is broken during move. What is the most likely reason for the vector behavior and what step-by-step fixes will make moves effective and safe in this codepath? Ladder L5

Over multiple projects we lose performance when classes that own heavy OS or GPU handles are copied instead of moved. Developers either forget to define moves or write moves that are unsafe. Which team-level habit change will reduce these problems: what code patterns, automated checks, or small training exercises should we introduce so ownership-bearing classes are movable, noexcept where possible, and reviewed correctly? Ladder L6