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

Comece executando a reprodução de pty fornecida com Python 3.14 e compare seu comportamento com o Python 3.13. Investigue o tratamento de bracketed paste pela REPL do CPython e a newline enviada imediatamente após a sequência de fechamento; considera-se concluído quando essa newline executa o bloco colado sem exigir um atraso, com o comportamento coberto por um regression test.