Add new metadata field for locking a kernel

As discussed in https://github.com/jupyterlab/jupyterlab/issues/19050, the proposal introduces a new top-level notebook metadata field, `kernel_lock`, which indicates whether a notebook's chosen kernel should be treated as locked. The motivation for this feature is to address an often encountered issue in educational settings, where beginners accidentally change the kernel and thus break the notebook's execution environment, making it confusing and difficult to diagnose, especially for new users. Beyond these scenarios, it can also be helpful for authors who create a notebook and want to share it with a specific kernel in mind.

This PR https://github.com/jupyterlab/jupyterlab/pull/19142 offers a reference implementation in `JupyterLab`, and can be seen as a working POC and a starting point for the discussion.

During the initial discussion, it has been brought up that other frontends might also want to respect this convention. As such, this issue is also intended to open the discussion here on the locking mechanism, in particular with regards to the naming of the metadata field (currently `kernel_lock`), as well as the semantics of possibly adopting the feature across other frontends.

Any feedback or thoughts on this would be appreciated.

cc: Thank you @krassowski for bringing this up in the linked issue.

Start by reading the linked nbformat discussion and the JupyterLab pull request 19142, which provides a reference implementation. Clarify the metadata field name, locking semantics, and cross-frontend expectations; the issue is ready for implementation only after those design questions have a decision.

Written by the indexing model from the issue text.