multiprocessing.Queue.empty() returns False after all producers have exited on Windows 3.13.3

On Windows 11 with CPython 3.13.3 official installer, Queue.empty() incorrectly returns False when the producer process has already terminated, allowing a later-started consumer to successfully get() all buffered items. This contradicts the documented behaviour that empty() is only reliable while producers are alive.
To Reproduce
Save as clean_test.py:
Python

from multiprocessing import Process, Queue

def x(q):
    for i in range(4):
        q.put(i)

def y(q):
    cnt = 0
    while True:
        if q.empty():
            break
        q.get()
        cnt += 1
    print('实际 get 次数：', cnt)

if __name__ == '__main__':
    q = Queue()
    p1 = Process(target=x, args=(q,))
    p2 = Process(target=y, args=(q,))
    p1.start()
    p1.join()          # producer already dead
    p2.start()
    p2.join()

Run:
powershell

python clean_test.py
Expected behaviour
Should print 实际 get 次数： 0 (consumer sees empty queue).
Actual behaviour
Prints 实际 get 次数： 4 (consumer successfully gets all items).
Environment
OS: Windows 11 (build 22631)
Python: 3.13.3 (tags/v3.13.3:6280bb5, Apr 8 2025, 14:47:33) [MSC v.1943 64 bit (AMD64)]
Installer: official python.org x64 exe
File SHA-256: 4D8746575FF5D9062D159EB0C382589DBFEC56C942D23DA57E44CF1920312D57
Additional context
The same script always outputs 0 on Linux (CPython 3.11-3.13) and on Windows 10 with 3.11.
Appears to be Windows-specific and version-specific (3.13.3).

Comece com o reprodutor clean_test.py e execute-o no Windows 11 com CPython 3.13.3; em seguida, compare os resultados do Windows 10 e do Linux descritos na issue. Investigue multiprocessing.Queue.empty() e o ciclo de vida de producer/consumer; considera-se concluído quando o caso do Windows 3.13.3 relata 0 itens após o producer sair, sem introduzir regressões nos ambientes de comparação.