Fix a crash in mpack_encode_list on a FT build - #1252

Moving the size read under the lock fixes the original race, but there is still a crash when another thread modifies a nested list while the outer list is being cleared. I reproduced this on Python 3.14 with the GIL disabled, using the code below without an enc_hook.

CPython can temporarily release the outer list's lock while waiting for the inner list's lock. For example, with inner = [1, 2, 3] and outer = [inner, 99], this sequence is possible:

Thread 1: locks outer and saves len = 2.
Thread 2: modifies inner while holding its lock.
Thread 1: waits for inner's lock, temporarily releasing outer's lock.
Thread 3: clears outer.
Thread 1: resumes encoding with len = 2, although outer is now empty.

The next access to outer through PyList_GET_ITEM can then be out of bounds. The loop also uses element references without owning them across recursive encoding. Please cover this case and protect both the element references and the list accesses. The number of encoded items must also match the length already written in the MessagePack header.

import threading
import msgspec

inner = [1, 2, 3]
outer = [inner] * 64
stop = threading.Event()

def churn_inner():
    while not stop.is_set():
        inner.append(0)
        inner.pop()

def shrink_outer():
    while not stop.is_set():
        outer.clear()
        outer.extend([inner] * 64)

def encode():
    for _ in range(20000):
        msgspec.msgpack.encode(outer)

mutators = [threading.Thread(target=f)
            for f in (churn_inner, churn_inner, shrink_outer)]
encoders = [threading.Thread(target=encode) for _ in range(4)]
for t in mutators + encoders:
    t.start()
for t in encoders:
    t.join()
stop.set()
for t in mutators:
    t.join()

There is also a slowdown on regular GIL builds: Py_EnterRecursiveCall now runs even for empty lists. In a local macOS microbenchmark, encoding [[] for _ in range(1000)] was about twice as slow as before. Moving the recursion check after the empty-list path removed the slowdown. Please keep that fast path, as required in #1249.

@Siyet friendly ping :)
I want to get this PR merged, so I can start working on other fixes.