Per-cell execution timeout remains absent in JupyterLab 4.x despite kernel interruption and idle culling mechanisms

Context

Jupyter Server 2.x introduced KernelManager.cull_connected to control whether kernels with active frontend connections but no recent code execution are culled, complementing the existing cull_idle_timeout and cull_interval settings. However, these idle-culling parameters only affect kernels that have gone completely inactive; they do not interrupt a cell that is actively executing, even if that execution exceeds any reasonable time bound.

Problem

The Jupyter protocol defines an interrupt_request message, yet the kernel's response is implementation-dependent. IPython converts it to a KeyboardInterrupt at the next bytecode boundary, while kernels running native extensions or blocking system calls may ignore the signal entirely. No core JupyterLab 4.x feature enforces a maximum cell execution time, and third-party extensions such as jupyterlab-execution-timeout rely on kernel-specific APIs that do not generalize across kernel types.

Open questions

1. What configuration or extension approaches provide reliable per-cell timeouts across both IPython and non-IPython kernels in JupyterLab 4.x?
2. How does the cull_connected setting interact with long-running cells that maintain active frontend connections but produce no output?
3. Is there a protocol-level proposal to standardize execution timeouts in the Jupyter message specification?