PyTorch Dynamo guard paths race into use-after-free

PyTorch Dynamo can free compilation guard state while invalidation and cache-update code are still using it, creating a use-after-free under concurrent reset.

The affected paths are reached from Python through raw pointers on the guard manager: invalidation from a weak-reference finalize callback (any thread), and diff-guard root updates on every recompile. Both read ownership and code-object fields before taking the code lock, and neither rechecks under the lock that the entry is still alive. A concurrent torch._dynamo.reset() in that window frees the objects. The same race is possible on GIL builds at a bytecode boundary.

Invalidation also clears back-references only after releasing the lock, so a concurrent update can reattach a live diff-guard root to an entry that was just invalidated, breaking the extra-state invariant those structures are meant to uphold.

The intended repair is to reach the lock without dereferencing the raw pointer (for example by holding a strong reference to the code object and an isolate id on the guard manager), look the entry up under the lock, and return early if it is gone.