Fixes #640: Serialize polymorphic multiobject through-model creation against concurrent readers

[bctiemann]

Closes: #640

Summary

• Fixes a race in MultiObjectFieldType.create_polymorphic_m2m_table() (called once, when a polymorphic multiobject field is first created) where the through-model class was built and registered with Django's app registry, and only afterward had its source FK repointed at the caller's model class — all without holding CustomObjectType._global_lock.
• A concurrent get_model(no_cache=True) call (e.g. from a request rendering the delete-confirmation page, or a raw DELETE) is lock-protected only on its own side. It could land in that window, find the through model already registered, and repoint source at its own (different, but table-equivalent) model instance instead — leaving the through's FK and whatever get_model() subsequently caches pointing at two different Python classes for the same table.
• That class-identity mismatch is what produced the reported ValueError: Cannot query "X": Must be "TableYModel" instance. and RecursionError — a recurrence of ValueError: Cannot query "<object_name>": Must be "Table4Model" instance when deleting Custom Object via UI #477 in a different code path.
• The fix wraps the build+register+repoint sequence in the same global lock _after_model_generation()'s caller already uses, closing the gap.

Note: The only material change here is to move the schema probe in create_polymorphic_m2m_table into the same CustomObjectType._global_lock construct that has remedied similar race conditions in the past. The unit tests that exercise this operation have very long docstrings/comments, but this is after significant trimming-down already; I feel the context the documentation provides will be helpful in diagnosing any future similar issues.

Root cause detail

_after_model_generation()'s own reuse-or-create check for polymorphic through models is already fully serialized — CustomObjectType.get_model() wraps that whole call in _global_lock, so two concurrent readers regenerating the same COT never race each other there. The actual gap was on the writer side (field creation), which never took that lock at all.

Test plan

• Added PolymorphicMultiObjectConcurrencyTestCase.test_forced_registration_interleaving_stays_consistent, which deterministically forces the exact writer/reader interleaving via a mocked apps.register_model() hook (rather than relying on real thread-scheduling luck, which does not reliably land inside this narrow window).
• Verified: 5/5 runs fail against the unfixed code (assertion mismatch between the through model's source FK class and what get_model() returns), 5/5 runs pass with the fix.
• ruff check clean on both changed files.
• Full test_deletion suite passes (2 pre-existing, unrelated errors from a netbox_branching import artifact under the non-branching test configuration, present on unmodified main too).