PyREPL bracketed paste issue

Bug report

Bug description:

As expected, when sending code to the REPL within bracketed paste, newlines are always interpreted as actual new lines and not as block execution.
But newlines sent just after closing the bracketed paste are interpreted also as newline in Python 3.14, while they should be interpreted as block execution.
If a small delay is added between closing the bracketed paste and sending the newline, the newline is actually interpreted as block execution.

Originally encountered with Neovim's chansend while sending a block of code to a REPL to execute it, but reproduced below in Python:

import os
import pty
import time
import signal

# Start a REPL
pid, fd = pty.fork()
if pid == 0:
    os.execlp("python", "python")
time.sleep(1)

# Send bracketed code and then newline
os.write(fd, b"\x1b[200~print('Help! I need somebody')\nhelp()\n\x1b[201~")
# time.sleep(0.01)
os.write(fd, b"\n")

# Display output
time.sleep(1)
data = os.read(fd, 4096)
os.kill(pid, signal.SIGTERM)
print(data)

On Python <=3.12, the script errors because bracketed paste is not supported.
On Python 3.13, the help is displayed as expected.
On Python 3.14 and 3.15, it ends up with a line continuation ...: and does not show the content of help(), unless there is a time.sleep between sending the bracketed code and the newline.

When sending to bash, the newlines after the closing of the paste are always interpreted as block execution.

CPython versions tested on:

3.14

Operating systems tested on:

Linux

Linked PRs

• gh-157270

Commencez par exécuter la reproduction pty fournie avec Python 3.14 et comparez son comportement avec celui de Python 3.13. Étudiez la gestion du bracketed paste par la REPL de CPython ainsi que la newline envoyée immédiatement après la séquence de fermeture ; le travail est considéré comme terminé lorsque cette newline exécute le bloc collé sans nécessiter de délai, et que le comportement est couvert par un regression test.