We need a feature to run the CasperJS-based browser tests against the SlimerJS engine (Gecko/Firefox) in addition to PhantomJS (WebKit). Currently the test infrastructure only runs with PhantomJS. The goal is to allow developers to exercise the same test suite on both engines, and eventually to run SlimerJS tests on CI.

**Observed gaps**:

- The test-runner command-line currently has no way to request SlimerJS. There should be an option (e.g., `--slimerjs`) that tells the system to use SlimerJS when available.
- SlimerJS has a different exit-code behavior: CasperJS always returns exit code 0 even on test failure. This leads to false positives if we rely on the process exit code alone to signal success/failure. The controller must capture output and inspect it for failure indicators when running under SlimerJS.
- SlimerJS respects the "onbeforeunload" dialog (the "Are you sure you want to quit?" prompt), causing test hangs when the page attempts to navigate away. PhantomJS silently ignores these.
- The notebook interface can load asynchronously under SlimerJS (Gecko) and races may occur where tests start before `IPython.notebook` is available. A wait-for-ready step is needed before executing tests.
- The `isArray` helper used in widget tests relies on `toString.call(a)` which throws in certain contexts in SlimerJS; this needs a fallback to `Array.isArray`.
- The `recursive_compare` logic assumes `a instanceof Object` is sufficient for detecting objects, but in Gecko some values cross compartments and fail that check; the condition should also account for `typeof a == 'object'`.
- The engine type must be passed down to the `casperjs test` invocation via the `--engine` flag.
- The test runner should check for the presence of the selected engine binary (`slimerjs` or `phantomjs`) and disable the JS test group entirely if the required engine is not found.

**Expected behavior**:
- Running `iptest --slimerjs` (or the equivalent controller option) will run the notebook JS tests using SlimerJS if it is installed; otherwise it falls back to PhantomJS or raises a clear error if neither is present.
- Test failures under SlimerJS are correctly detected and reported (non-zero overall exit status), despite CasperJS always returning 0.
- The onbeforeunload handler is neutralized in the tested page when running under SlimerJS, preventing hangs.
- The test runner ensures the notebook is fully loaded before beginning any test steps.
- The widget comparison helpers work across both engines.

This is not about adding new test cases—only about making the existing JS test suite run correctly and predictably on the SlimerJS engine, and providing a command-line switch to select it. The fix should be robust to the differences between PhantomJS and SlimerJS without breaking the PhantomJS (default) path.


As the kernel protocol moves toward richer output representations, the `InteractiveShell.user_variables` and `user_expressions` methods need to be upgraded to return mime-bundle data instead of plain `repr()` strings.

**Current behavior**
- `user_variables` returns a dict keyed by variable name, where each value is a `repr()` string of the variable (or a plain `[ERROR] ...` string on failure).
- `user_expressions` does the same for evaluated expressions.
- There is no structured error information.

**Desired behavior**
- Each entry in the returned dict should be a rich display-data structure (a sub-dict) compatible with `display_data` messages.
- For a successful lookup/evaluation, the sub-dict should contain:
  - `status: 'ok'`
  - `data`: a mime-type → content dict produced by the shell's existing `display_formatter` (include all active mime types).
  - `metadata`: the metadata dict from the formatter.
- For a failure (e.g., missing variable, exception during expression evaluation), the sub-dict should contain:
  - `status: 'error'`
  - `ename`: the exception type name.
  - `evalue`: a stringified exception value.
  - `traceback`: an exception-only traceback string (the kind produced by `get_exception_only` on the shell's `InteractiveTB`).
- The methods should not catch broad exceptions that hide programming errors; they should handle the expected user-namespace and evaluation failures and let unexpected internal errors propagate as before.

**Non-functional requirements**
- Use the existing `DisplayFormatter` instance (`self.display_formatter`) already available on the shell.
- Reuse existing traceback-formatting helpers rather than constructing ad-hoc error strings.
- Do not change the public signature of either method.
- The change is an internal protocol upgrade intended for use by the frontend/kernel message layer, so existing callers that expected plain strings will need updating; this is acceptable.

**Acceptance criteria** (to guide implementation)
- For a variable like an object with a custom `_repr_html_`, the result includes `text/html` in its `data`.
- For an existing integer variable, `text/plain` contains the usual repr.
- Requesting a variable that does not exist yields `status: 'error'` with `ename: 'KeyError'`.
- An expression like `1/0` yields `status: 'error'` with `ename: 'ZeroDivisionError'`.
- The error `traceback` is a string that looks like the exception-only traceback (not a full multi-line traceback).

Implement this in `IPython/core/interactiveshell.py` and update the tests accordingly.

user_variables and user_expressions use rich repr API


**Title:** `atomic_writing` loses file permissions and platform‑specific flags

**Description**
The `IPython.utils.io.atomic_writing` context manager is meant to atomically replace a file only if the entire write succeeds.
Currently it writes to a temporary file in `tempfile.mkstemp` style, then renames that temporary file over the destination.
Because the new file is created with default permissions (and no flags), any custom permissions or filesystem‑specific metadata previously set on the destination are lost after the replacement.

We should copy the relevant metadata from the *original* file (the one at `path`) to the *temporary* file before the final rename, so that the replacement preserves:

1. **Permission bits** – the mode returned by `os.stat(path).st_mode`, at least the permission portion (copied with `shutil.copymode` or equivalent).
2. **Platform‑specific flags** – on systems where `os.chflags` and `os.stat().st_flags` exist (e.g. BSD/macOS), those flags should also be preserved when possible.

**Edge cases / safety**

- If the destination file **does not exist** when `atomic_writing` is entered, there is nothing to copy; metadata copying should be skipped gracefully without raising an error.
- Any failure during metadata copying itself (e.g. permission error on the temp file) should be treated as non‑fatal – the atomic write must still succeed, falling back to the default metadata on the temporary file.
- The behaviour on Windows must remain functional. `os.chflags` is not available there, so the flag‑copying part must be conditional; `copymode` should still work if the underlying OS supports it, but the copy must not break the atomic mechanism.

**Acceptance criteria**

- After an `atomic_writing` that overwrites an existing file, `os.stat(path).st_mode` (permission bits) is identical to what it was before entering the context.
- On systems with `os.chflags`, the file flags are preserved across the atomic write.
- If the path does not exist beforehand, no exception is raised; a new file is created with default permissions as before.
- Any `OSError` during the metadata copy step is ignored and does not prevent the file from being written.


We need to remove the built-in “native kernel” spec from `jupyter_client` and instead have the `ipython kernelspec install-self` command delegate to `ipython_kernel` to generate and install the correct kernel spec.

Currently, the native kernel (python2 or python3 depending on the runtime) is hard-coded inside `KernelSpecManager`:
- `find_kernel_specs` always includes a `NATIVE_KERNEL_NAME` entry, so it appears in `ipython kernelspec list` even when nothing has been installed.
- `get_kernel_spec` likewise synthesizes a `KernelSpec` for `python` or `python3` on the fly.
- `install_native_kernel_spec` manually builds the kernel dictionary (using `make_ipkernel_cmd` from `jupyter_client.launcher`) and copies a resource directory bundled inside `jupyter_client`.

This is backwards – the kernel specification detail should live in the kernel implementation, not in the client library. The `ipython_kernel` package already provides `write_kernel_spec` and related helpers; `install-self` should simply call that and then install the result as an ordinary kernel spec (reusing the existing `install_kernel_spec` machinery).

What needs to happen:
1. Remove all traces of a built-in native kernel from `jupyter_client`. This means `find_kernel_specs` and `get_kernel_spec` must stop synthesizing the native spec – after this change the native kernel will only show up in the list if it has been explicitly installed (via `install-self` or by dropping a spec into a kernels directory).
2. Rewrite `install_native_kernel_spec` (the handler behind `ipython kernelspec install-self`) so that it imports `write_kernel_spec` from `ipython_kernel.kernelspec`, calls it to generate the spec directory, and then passes that directory to `install_kernel_spec` with `replace=True`.
3. Clean up any helpers that are no longer needed because the native spec logic is moving out: `_pythonfirst` (custom sort key for listing), `_native_kernel_dict`, `_native_kernel_resource_dir`, `make_ipkernel_cmd`, and `swallow_argv` can all go, along with any stale imports or tests that depend on them.
4. The `__all__` of `jupyter_client.launcher` should be updated to only expose `launch_kernel`.

The observable effects:
- `ipython kernelspec list` no longer shows a “python”/”python3” kernel before `install-self` has been run.
- `ipython kernelspec install-self` still installs the correct native kernel spec, but now it does so by asking the kernel package to produce it.
- The deprecated command label should reflect the change – something like “[DEPRECATED] Install the IPython kernel spec directory for this Python.”

I’m not looking for a big architectural overhaul – just shifting the ownership of the kernel spec generation to `ipython_kernel` and removing the duplicated/out-of-place logic from `jupyter_client`.

remove native kernel spec from jupyter_client


We need to add kernel name support to the sessions REST API and move kernel lifecycle management out of the HTTP handlers into the `SessionManager`.

Currently the session model returned by the API only includes a `kernel.id`. It should also include `kernel.name`, similar to how the kernel listing endpoint returns it. The creation request (`POST /api/sessions`) should accept a `kernel.name` field, defaulting to `'python'`.

At the same time, the session creation and deletion handlers currently import `notebook_manager` and `kernel_manager` directly, call `start_kernel`, `shutdown_kernel`, and look up the kernel’s working directory. This violates the separation between the service layer and the web layer. Those duties belong to `SessionManager`. The handlers should only call `SessionManager.create_session(name, path, kernel_name)` and `SessionManager.delete_session(session_id)`. The manager itself should use an injected kernel manager and notebook manager to resolve the kernel path, start the kernel during session creation, shut it down during session deletion, and construct the full kernel model (id + name) when reading sessions.

Details:
- The `SessionManager.create_session` signature should accept `kernel_name` (with a sensible default) instead of a raw `kernel_id`. It should start the kernel internally.
- `SessionManager.row_factory` (or whatever produces the API model for a stored session) should use the kernel manager to build the kernel sub-object rather than producing a dict with only `id`.
- `SessionManager.delete_session` should shut down the associated kernel after confirming the session exists.
- The session manager must receive its kernel manager and notebook manager instances, which the application’s initialization code should pass in when constructing the manager.

No changes to the database schema are needed—only the runtime model and the API contract should be affected. The existing tests for the sessions API and the session manager must continue to pass (after adjustment for the new expectations).


```
Title: %run: quoted arguments should not undergo glob expansion

Background
----------
The `%run` magic currently applies shell-style glob expansion to every
argument after splitting, regardless of whether the user wrapped the
argument in single or double quotes. The docstring even calls this out:
"Unlike real shells, quotation does not suppress expansions."

In real shells quoting disables globbing, so the current behaviour is
surprising and makes it impossible to pass a literal `*` or `?` to a
script without escaping it with backslashes (which is also supported,
but less convenient and different from how users expect quoting to work).

Request
-------
Make `%run` honour quoting when deciding whether to expand a glob
pattern.  When an argument is enclosed in single or double quotes, the
glob expansion step should be skipped for that argument.  The unquoted
form of the argument (i.e. after quote removal) should still be used,
and tilde expansion should still happen on it as before.

Examples (assume `foo.txt` and `bar.txt` exist in the working directory):

    # Unquoted glob – behaviour unchanged
    %run script.py *.txt     → sys.argv[1:] = ['bar.txt', 'foo.txt']

    # Quoted glob – new behaviour
    %run script.py "*.txt"   → sys.argv[1:] = ['*.txt']
    %run script.py '*.txt'   → sys.argv[1:] = ['*.txt']

    # Backslash escaping – unchanged
    %run script.py \*.txt    → sys.argv[1:] = ['*.txt']

    # -G flag disables all expansion – unchanged
    %run -G script.py *.txt  → sys.argv[1:] = ['*.txt']

Constraints / Edge Cases
------------------------
- The `-G` flag must continue to suppress *all* expansion (both glob and
  tilde) exactly as it does today.
- Backslash escapes for unquoted arguments must keep working.
- Single quotes are not recognised as quoting characters on Windows
  (this is a long-standing IPython limitation documented in the `%run`
  help).  It is acceptable if single-quote suppression of glob expansion
  only takes effect on POSIX, as long as double-quote suppression works
  on all platforms.
- If an argument contains unbalanced quotes, the parser currently raises
  under `strict=True` behaviour.  The safety net for `%run` should
  probably be lenient (non-strict) so that a malformed quoted argument
  falls back to the legacy, expand-everything behaviour rather than
  crashing.
- The docstring paragraph that currently states “Unlike real shells,
  quotation does not suppress expansions” must be updated to describe
  the new behaviour.

Implementation Notes (non-prescriptive)
---------------------------------------
The argument splitting happens inside `%run` and the glob expansion is
done via `shellglob`.  Today the implementation loses the information
about which tokens were originally quoted.  You will likely need to
preserve that information (e.g. by inspecting the raw command line
before/after splitting) and then skip `shellglob` for tokens that came
from quoted segments.

The existing `arg_split` function in `IPython.utils._process_common`
already handles POSIX vs non-POSIX modes; a variant that returns
`(token, was_quoted)` pairs could be a clean way to implement this,
but the choice is left to the implementer.

Related: #12726.
```

Fix #12726: %run honors quotes when expanding glob args


```
Bug: Pretty printer ignores newlines in `__repr__` output when used inside groups

When an object does not define `_repr_pretty_` and the pretty printer falls
back to `repr()`, any newline characters in the `repr()` result are emitted
as literal newlines. This breaks the printer’s indentation machinery.
If the object is printed inside a group (for example, inside a list, a
dictionary, or a parent object’s custom `_repr_pretty_` that uses
`p.group()`), the continuation lines are not indented to the current group
depth.

Example that demonstrates the problem:

```python
import IPython.lib.pretty as pretty

class MultiLine:
    def __repr__(self):
        return "A\nB"

class Container:
    def _repr_pretty_(self, p, cycle):
        with p.group(4, "Container(", ")"):
            p.pretty(MultiLine())

print(pretty.pretty(Container()))
```

Current behavior: the newline inside `"A\nB"` is output literally, causing
`B` to appear at column 0, outside the group.  The expected behavior is that
each embedded newline acts as a break opportunity (equivalent to
`p.break_()`), so that the printer can re-indent continuation lines to
match the current indentation level.  This would be consistent with how
`p.break_()` calls work in user-defined `_repr_pretty_` methods, and with
how newlines are handled in other parts of the pretty printing framework.

Impact: objects with multi-line `__repr__` outputs appear misaligned and
disrupt the visual structure when they appear inside grouped pretty-printed
output.
```

Uses p.break_() when repr() is used for printing


Make `print_figure` and `retina_figure` return base64-encoded strings instead of raw bytes for binary image formats when requested, and update `select_figure_formats` to use this for all registered binary formatters.

Right now `print_figure` returns raw bytes for binary outputs (png, jpg, pdf, retina). The Jupyter display pipeline expects the MIME payload for binary image types to be a base64 string; bytes are accidentally made to work because the serializer’s `default` function base64-encodes them. That behaviour was ambiguous on Python 2 but now we can send the correct type directly.

Desired behaviour:
- Add an optional `base64` parameter to `print_figure` and `retina_figure` (default `False` to preserve backward compatibility of the return type).
- When `base64=True`, return a base64-encoded **string** for binary formats. SVG should remain an unencoded plain text string (it is already text, not binary).
- In `select_figure_formats`, when registering formatters for `png`, `retina`, `jpg`/`jpeg`, and `pdf`, supply `base64=True` so that the formatters directly receive a string. SVG should still be registered without base64.
- Ensure empty figures still return `None` regardless of the base64 flag.

print_figure return base64 str instead of bytes


**Feature: Emit warnings on failed formatter calls**

Currently, when an IPython formatter (e.g., HTML, LaTeX, PNG, JSON, or the plain‑text formatter) tries to format an object and the formatting code raises an exception, the exception is silently caught and the formatter returns `None`. This makes debugging custom `_repr_html_`, `_repr_latex_`, or registered type printers very difficult because no indication of the failure is produced.

We need the formatter machinery to **emit a warning** whenever a formatter call fails. The warning should:
* include the **mime type** of the failing formatter (e.g. `text/html`, `text/latex`, `text/plain`, …),
* include a description of the **exception** that was raised,
* still cause the formatter to **return `None`** so that existing fallback behaviour is preserved.

This new warning behaviour must apply to **all built‑in formatters** (HTML, SVG, PNG, JPEG, LaTeX, JSON, JavaScript) as well as to the plain‑text formatter. For the plain‑text formatter, failures during pretty‑printing and failures from `_repr_pretty_` methods should also produce warnings.

**Example:**
If an object’s `_repr_html_` method raises a `ZeroDivisionError`, calling the HTML formatter should output a warning indicating that an HTML formatter error occurred and that a division‑by‑zero was involved, before returning `None`.


**Bug: Hidden directories not properly hidden from notebook tree view and directory listing**

The notebook server’s static file handler (`AuthenticatedFileHandler`) correctly prevents access to hidden files and directories. It considers a file/directory hidden if any path component starts with `.`, or if the BSD `UF_HIDDEN` flag is set on the file. However, other parts of the notebook interface do not apply the full set of hidden checks consistently:

- **Notebook directory listing** (`FileNotebookManager.list_dirs`): only checks whether the *immediate* directory name starts with `.`; it does not inspect parent components for dot‑prefixes and ignores the `UF_HIDDEN` flag entirely. As a result, a visible directory that contains a subdirectory whose parent is hidden may still appear in listings, and directories flagged hidden only via `UF_HIDDEN` are not suppressed.

- **Tree handler** (`/tree/...`): only checks `path_exists` before rendering the tree page. If a path points to a hidden directory, the tree view will be served, exposing the directory’s contents despite the file handler returning 403 for individual files inside it.

The hidden‑check logic inside `AuthenticatedFileHandler.forbid_hidden` (dot‑prefix walk up the path, plus `UF_HIDDEN` check) already implements the correct policy, but it is duplicated there and absent elsewhere.

**Expected behavior**

1. Any operation that lists or serves directory contents should treat a hidden path (according to the same definition used by `AuthenticatedFileHandler`) as if it does not exist: return a 404 response and never include it in directory enumerations.
2. The hidden‑detection logic (dot‑prefix in any path component, and `UF_HIDDEN` flag) should be implemented exactly once, in a shared utility, and reused by the file handler, the notebook manager’s directory listing, and the tree handler.

**Impact**

Users can browse hidden directories through the notebook tree UI, potentially exposing sensitive local files (e.g. `.ssh`, `.git`, configuration directories). The inconsistency also means that static asset requests for the same paths are correctly blocked, while the tree and API listing surfaces leak them.

Creating and testing IPython.html.utils.is_hidden.


Improve prompt-stripping to handle cells that begin without the first prompt.

Currently, when a user copies an IPython or Python shell example starting from a continuation line (e.g., `...` or `   ...:`) instead of from the initial prompt (`>>>` or `In [1]:`), the prompt-stripping transformer leaves those continuation prompts in place, producing invalid code. For example, pasting only:

```
... 123
... 456
```

should produce `123\n456`, but instead it passes through unchanged.

The fix should scan the first **two** lines of a cell for any prompt pattern (both primary and continuation). If a prompt is found on either line, stripping should be enabled for the entire cell, removing all prompt prefixes from every line. If no prompt is detected in the first two lines, the transformer must leave the cell untouched (current behavior) to avoid stripping prompt‑like prefixes that legitimately appear inside multi‑line strings or other data. This ensures that pasted snippets missing the very first prompt are handled correctly while false‑positive stripping is still avoided.

Strip prompts even if the prompt isn't present on the first line.


Fix `leading_indent` so that it properly removes the *minimum common leading indentation* from every line in an input cell. The current logic only strips the whitespace of the first non‑comment line, which means a cell whose first line is an indented comment keeps all its leading spaces. The function should instead dedent all lines uniformly (like `textwrap.dedent`), stripping exactly the longest whitespace prefix that appears on every line.


**Feature Request: Automatic language-aware syntax highlighting for cell magic cells in nbconvert**

When IPython’s nbconvert renders a notebook cell that starts with a cell-level language magic (for example `%%R`, `%%bash`, `%%octave`, `%%perl`, `%%ruby`), the cell’s content should be syntax-highlighted according to the indicated language rather than using the IPython/Python highlighter.

**Observed behaviour today**
- Cells with `%%R` (or similar) are highlighted as if they were IPython code, making multi-language notebooks harder to read in HTML or LaTeX output.

**Expected behaviour**
- If a cell begins (after optional leading whitespace) with one of the known language cell magics (`%%R`, `%%bash`, `%%octave`, `%%perl`, `%%ruby`), the syntax highlighter should automatically switch to the corresponding Pygments lexer (e.g. `r`, `bash`, `octave`, `perl`, `ruby`).
- Cells that do **not** begin with such a magic should continue to be highlighted as IPython.
- This detection must be robust against false matches: if a cell merely contains the string `%%R` inside an expression (for instance `print("%%R")`), it must **not** trigger a language switch.
- The change should work for both `highlight2html` and `highlight2latex` outputs produced by nbconvert.

**Acceptance criteria**
1. A notebook cell whose first line is `%%R` (or any of the listed magics) is highlighted with the correct language lexer when converted to HTML or LaTeX.
2. A cell containing a literal `%%R` string that is not a cell-level magic line continues to be highlighted as IPython.
3. Existing end-to-end highlighting of ordinary IPython cells remains unchanged.

Select adequate highlighter for cell magic languages


```
Title: Audio from list data without numpy raises AttributeError on Python 3

Description:
When an `Audio` object is instantiated with a list of audio samples (e.g., `Audio(data=[0.1, -0.2, 0.3], rate=44100)`) and numpy is NOT available, the fallback validation logic inside `Audio._validate_and_normalize_without_numpy` crashes with an `AttributeError`. This happens because the existing nested‑list detection relies on `iter(data).next()`, which is a Python 2 idiom and does not exist on Python 3 iterators.

As a result, any user who passes a simple list of numbers without having numpy installed gets a traceback instead of a working audio object. This affects all recent IPython versions that target Python 3.

Expected behavior:
- A flat list of numbers (mono audio) should be processed and displayed correctly on Python 3 when numpy is not present.
- A nested list (e.g., `[[0.1, -0.2], [0.3, 0.4]]` representing multi‑channel audio) should still be rejected with a clear `TypeError` containing the existing message “Only lists of mono audio are supported if numpy is not installed”.
- The fix should avoid any dependency on Python‑2‑only iterator methods, be 3.x compatible, and preserve the existing error message and contract.
```

Fix Audio from data without numpy on Python 3.


Make `nbformat.read` and `nbformat.write` accept a string path in addition to a file-like object for the `fp` argument. When a string is given, treat it as a filesystem path: open the file in text mode with UTF-8 encoding. For reading, open for reading and then delegate to the normal file-like handling; for writing, open for writing (creating/truncating) and delegate. All other behavior (conversion, version parameters, existing file-object logic) must remain unchanged, and the change must work across Python 2 and 3.

Make nbformat.(read|write) accept file-like object or path


# Feature request: token-by-token autosuggestion acceptance

The terminal IPython’s autosuggestion feature currently lets users accept the full suggestion (e.g., via right-arrow in vi insert mode) or accept the next word (Escape f). I’d like a more granular way to accept suggestions: **accept the next Python token**, so I can fill in complex statements one small piece at a time.

### Desired behavior

- **New keybinding** (suggestion: *Ctrl+Right arrow*) that, when an autosuggestion is shown, accepts the next *Python token* from the suggestion.
- **Fallback** when no suggestion is shown: the keybinding should behave like the standard forward-word command, matching the pattern used by the existing word-accept fallback.
- **Token definition** should use Python’s tokenizer (e.g., `tokenize` module) so it respects Python syntax boundaries: names, operators, delimiters, keywords, etc.
- **Usability grouping**: to avoid too many keystrokes, if the token just accepted is a single character (e.g., `:`, `,`, `=`), the next token should be accepted automatically in the same action. For example, with cursor at `def out(` and suggestion `tag: str, n=50):`, pressing the shortcut once should fill in `tag: ` (the name `tag`, the colon, and the following space) rather than stopping after only `tag`.
- Should be integrated into the existing autosuggestion infrastructure alongside the current accept/accept_word handlers, and registered as a terminal keyboard shortcut.

### Motivation
Right now, if a parameter name or punctuation is part of a long suggestion, I have to either accept the whole thing and delete what I don’t want, or accept a full word at a time which still jumps over important separators. Token‑by‑token completion would make editing function signatures, expressions, and other structured Python input much smoother.


```
Title: Fix Session object sharing and disable message signing for in-process kernel

The in-process kernel (`IPython.kernel.inprocess`) currently has inconsistent
Session handling that causes problems with message routing and verification
when using the kernel manager and client together.

There are two concrete issues:

1. **No shared session across manager, kernel, and client.**
   `InProcessKernelManager` and `InProcessKernel` each create their own
   `Session` object independently, and client code often constructs clients
   without passing any session. This means the manager, kernel, and client
   end up with different session identifiers and signing keys, breaking
   message ID tracking, header matching, and any protocol-level checks that
   rely on the session.

2. **Message signing should be disabled for in-process use.**
   The session uses HMAC signing by default, which is unnecessary (and a
   performance waste) for in-process communication. We should configure the
   session with an empty signing key (`key=b''`) so that messages are not
   authenticated. This is safe because the transport is a local function
   call.

The desired behaviour and invariants are:

- The `InProcessKernelManager` should create a `Session` with `key=b''` and
  no keyfile, and should pass that exact session to the `InProcessKernel`
  when starting it (so that they share the same session object).

- The `InProcessKernel` itself should *not* create its own default session
  that uses a random key. When constructed by the manager, it must use the
  session provided by the manager. If constructed standalone (e.g., in some
  test scenarios), it should still use an empty-key session to avoid
  undesired signing.

- When a `KernelClient` is obtained from the manager via `manager.client()`,
  the client must inherit the same session object (this likely already
  happens, but the session creation points need to be consistent). Any code
  that manually instantiates a `BlockingInProcessKernelClient` (e.g., in
  tests) must also pass `session=kernel.session` or use `manager.client()`
  to ensure session identity.

- No behavioural effect for users who use `InProcessKernelManager` as a
  library: the in-process kernel should continue to execute code, return
  results, and handle completions, inspections, etc., but now message
  signing overhead is eliminated and the session-related internal
  consistency is correct.

Please make the necessary changes to the in-process kernel module to
enforce these rules.  As a consequence, any tests that construct clients
directly should switch to `manager.client()` where appropriate, or
explicitly attach the kernel’s session to avoid mismatches.
```

fix Session passing around in kernel.inprocess


In Python 3.10, `inspect.getsource`, `inspect.getsourcelines`, and `inspect.getfile` can raise `OSError` for certain objects that have no accessible source or file (e.g., built‑in types, classes defined in `__main__`). Previously these raised `TypeError`. This behaviour change is documented in CPython issue bpo-44648.

IPython’s introspection system (used by `?`, `??`, `pinfo`, `psource`, `pfile`, and other inspection frontends) currently only catches `TypeError` in its internal helpers that wrap those `inspect` calls. As a result, on Python ≥ 3.10, trying to inspect such objects crashes with an unhandled `OSError`.

We need to update IPython’s introspection helpers so that they also catch `OSError` in analogous places where `TypeError` is already handled. The behaviour should be:
- When source, source lines, or file information cannot be retrieved because of an `OSError` (or a `TypeError`), the helpers should return `None` or silently skip the information, exactly as they would have done for a `TypeError` on older Python versions.
- The fix must cover all relevant introspection pathways that rely on `inspect.getsource`, `inspect.getsourcelines`, and `inspect.getfile`. This includes the fallback logic that tries an instance’s class when the instance itself cannot be inspected.

No other error types should be suppressed; only `OSError` and the already‑caught `TypeError` are relevant here. The end result should be that inspecting any object that lacks source or a file (builtins, `__main__` objects, etc.) never raises an unhandled exception on any Python version we support.

Handle OSError from inspect.getsource/getsourcelines (bpo-44648)


Subject: Class methods named "get" or "set" cause parse errors

In ECMAScript 2015, the tokens `get` and `set` are only interpreted as accessor keywords when they are immediately followed by a property name (an identifier or a computed property). When they are followed directly by an opening parenthesis `(`, they should be treated as ordinary method names—just like any other identifier—and define a method with that name on the class prototype or constructor.

Currently, the class body parser unconditionally treats every occurrence of `get` or `set` at the start of a class element as the start of an accessor, which leads to a syntax error for valid code such as:

```js
class Example {
  get(a, b, c) {
    return a + b + c;
  }

  static set(a, b) {
    return a * b;
  }
}
```

### Expected behavior
When the parser encounters `get` or `set` inside a class body, it should first skip any whitespace and inspect the next character.
- If the next non‑whitespace character is `(`, the token is **not** an accessor but a regular method name; the parser should then treat it as a method named `"get"` or `"set"` respectively.
- Otherwise (the usual case), it should continue to parse an accessor definition, expecting a property name (identifier or `[`).

This rule must hold for both instance methods and `static` methods.

### Impact
This prevents class definitions that use `get` or `set` as method names from being accepted by the engine, breaking compatibility with standard ES2015 (and later) code that relies on this syntactic distinction.


**Title:** Implement all Date.prototype getter methods

**Description:**
The JavaScript `Date.prototype` getters are currently stubbed and throw “not implemented” errors. This request asks for complete implementations of the getter methods listed in ECMA‑262 5th Edition sections 15.9.5.8 and 15.9.5.10–15.9.5.26, as well as `valueOf()` (15.9.5.2, which delegates to `getTime`). The feature should make every one of these methods observable from scripts, producing correct numeric results or throwing a `TypeError` when called on non‑Date objects.

**Acceptance Criteria:**

1. **Valid Date objects**
   For a `Date` instance whose time value is a finite number (a valid date):
   - `getFullYear()`, `getMonth()`, `getDate()`, `getDay()`, `getHours()`, `getMinutes()`, `getSeconds()`, `getMilliseconds()` return the corresponding component interpreted in **local time** (as defined by the host environment’s timezone and DST rules).
   - `getUTCFullYear()`, `getUTCMonth()`, `getUTCDate()`, `getUTCDay()`, `getUTCHours()`, `getUTCMinutes()`, `getUTCSeconds()`, `getUTCMilliseconds()` return the corresponding component interpreted in **UTC**.
   - `getTime()` returns the primitive time value (milliseconds since 01 January 1970 00:00:00 UTC), the same value that was used to create the instance.
   - `valueOf()` returns exactly the same number as `getTime()`.
   - `getTimezoneOffset()` returns the offset (in minutes) that must be added to the local time to obtain UTC. That is, for a given time value `t`, the offset equals `(t - localTime(t)) / 60000`. When the local timezone is behind UTC the result is positive; when it is ahead the result is negative.

2. **Invalid Date (NaN)**
   When the Date object’s time value is `NaN` (an “Invalid Date”), **all** of the methods listed above (including `getTime` and `getTimezoneOffset`) must return the numeric value `NaN`.

3. **Type check**
   If the `this` value is not an object, or if the object’s [[Class]] internal property is not `"Date"`, every method throws a `TypeError` exception. No other error types are thrown.

4. **Implementation constraints**
   - The implementation must use the existing date helper functions (`ecma_date_year_from_time`, `ecma_date_month_from_time`, `ecma_date_date_from_time`, `ecma_date_week_day`, `ecma_date_hour_from_time`, `ecma_date_min_from_time`, `ecma_date_sec_from_time`, `ecma_date_ms_from_time`, `ecma_date_local_time`) to extract components. No duplicate logic for the ECMA-262 date calculations is acceptable.
   - A new helper `ecma_date_timezone_offset` should be introduced to compute `getTimezoneOffset()` consistently with the existing `ecma_date_local_time`.
   - The stubs that currently call `ECMA_BUILTIN_CP_UNIMPLEMENTED` must be replaced with the real implementations.

5. **ECMA-262 alignment**
   The observable behavior must match the steps defined in ECMA‑262 5th Edition for each method, particularly the handling of NaN and the arithmetic specified in sections 15.9.5.8–15.9.5.26. The `valueOf` method must behave exactly as `getTime` as required by 15.9.5.2.

Implement builtin getters for Date object


# Bug: Heap buffer overflow in `re_parse_char_class` when handling incomplete `\x` / `\u` escapes

`re-parser.c` function `re_parse_char_class` processes `\x` and `\u` escape sequences inside character classes. The current implementation blindly advances the input pointer by the expected number of hex digits (2 for `\x`, 4 for `\u`) and then calls `lit_utf8_peek_next` on the new position to check for a range dash.

When the input string is truncated—e.g. `[\\x0` or `[\\u0020` without a closing `]`—the pointer moves past `input_end_p`, causing an out-of-bounds read. The parser must be hardened to reject these malformed escapes with a `SyntaxError` instead of overflowing into adjacent memory.

## Required behaviour

* Before advancing `input_curr_p`, validate that the expected count of valid hex digits is present using `re_hex_lookup`.
* If validation fails, throw a `SyntaxError` (no fallback to a literal character).
* After consuming the hex digits, only examine the following character for a range dash (`-`) when `parser_ctx_p->input_curr_p < parser_ctx_p->input_end_p`.
* If the end of input has been reached, skip the range logic and treat the code unit as a single character in the class.

The fix must apply to both `LIT_CHAR_LOWERCASE_X` and `LIT_CHAR_LOWERCASE_U` branches inside `re_parse_char_class`.

Fix heap buffer overflow in re_parse_char_class (#2352)


When parsing an assignment expression, the engine must reject invalid left-hand-side targets, such as string literals, by throwing a `ReferenceError` (or `SyntaxError`). This rejection must work reliably even when the offending expression appears after a `this` token in the same statement. For example, `g(this, 'a' = 1)` should cause a `ReferenceError` and must **not** silently evaluate and assign the value 1 to any variable or property.

The parser/bytecode emitter must not generate an assignment opcode that would treat a non-identifier literal (like a string literal) as an assignable identifier, regardless of preceding context. Any path that previously allowed such an assignment to succeed after a `this` expression must be corrected so that the error is raised.

Fix invalid assignment code generation. (#3695)


**Subject:** Array built-in (constructor, `isArray`, etc.) is missing; `[[DefineOwnProperty]]` on length does not follow ES5 rules when reduction fails

**Observed problem:**

1. The global `Array` object is not available. `typeof Array` returns `"undefined"`, and `new Array(...)` throws a reference error.
2. `Array.isArray` does not exist.
3. When reducing an array’s `length` property via `[[DefineOwnProperty]]` (for example, through `Object.defineProperty` on `length`) and a deletion of an indexed property fails (e.g. because the property is non‑configurable), the `length` property’s `writable` attribute is not updated correctly per the specification. In particular, the implementation appears to unconditionally set `writable` to `false` before attempting the reduction, even when the original `newWritable` was `false` and the reduction has not yet failed.

**Expected behavior:**

- The `Array` built‑in constructor must be available and create array objects according to ES5 §15.4.1–15.4.2.
- `Array.isArray` must behave as defined in §15.4.3.2.
- When reducing the `length` of an array via `[[DefineOwnProperty]]` (§15.4.5.1), step 3.l.iii.2:
  - If `newWritable` is `false`, set `newWritable` to `true` **only** when a deletion of an indexed property fails.
  - The `writable` attribute of the `length` property must not be changed before the deletion loop; it must only be set to `false` (via the new descriptor) if a deletion fails **and** the original `newWritable` was `false`.

**Context / impact:**

- Any script relying on `new Array(…)`, array literals, or `Array.isArray` is broken.
- Code that uses `Object.defineProperty` to seal array length or property attributes may observe incorrect `writable` values on the `length` property after a failed length reduction, leading to unexpected unchangeable lengths.


**Title:** `this.x = value` (and compound assignments) cause runtime errors or incorrect behavior

**Description**

When the left-hand side of an assignment expression (`=`, `+=`, `-=`, etc.) is a member access on the `this` object using a literal property name (e.g., `this.foo = bar`), the JavaScript engine fails to parse it correctly. Depending on the exact context, this either produces an internal parser error (crash) or generates invalid bytecode that leads to a `TypeError` at runtime, even when the code is valid.

**Steps to reproduce (observed behavior)**

Run any script that contains an assignment of the form:

```js
this.literal = someExpression;
```
or
```js
this.literal += someExpression;
```

In some cases the engine throws an `InternalError`, in others the assignment simply does not happen and subsequent accesses return unexpected values (e.g., `undefined` instead of the assigned value).

**Expected behavior**

The assignment should behave identically to any other property assignment: the property should be created or updated on the object, and the expression should evaluate to the assigned value. No errors should be thrown for syntactically valid input.

**Impact**

Any code that uses `this.property = value` inside methods, constructors, or class bodies is affected. Because such patterns are extremely common, the bug makes many real-world scripts unusable and blocks development. The fix should also cover compound assignment operators (`+=`, `-=`, etc.) on `this` with a literal key.

**Additional context**

The problem is specific to property accesses where the property is a fixed literal name (not a computed expression). It may also manifest inside comma expressions, function argument lists, or nested expressions that involve both `this` and an assignment. The expected invariant is that any left-hand side that ECMAScript allows must be accepted and executed correctly.

Fix assignment opcode transformation for CBC_PUSH_THIS_LITERAL (#3525)


**Ticket: Fix array literal parsing of `this` and adjacent assignment expressions**

**Context**
In `jerry-core/parser/js/js-parser-expr.c`, the parser emits `CBC_PUSH_THIS` (or `CBC_PUSH_THIS_LITERAL`) for the `this` keyword. When such an opcode appears inside an array literal, subsequent parsing of comma-separated elements may attempt to mutate the pending bytecode instruction, leading to incorrect runtime behavior or spurious `ReferenceError` exceptions. For example, a source snippet like `[this, u = u - 1]` can throw a `ReferenceError` or miscompile the assignment.

**Expected Behavior**
- `this` as an array element should evaluate to the correct `this` value, and the array should contain that value.
- Assignment expressions elsewhere in the same array (`u = u - 1`) should execute correctly and produce the expected side-effects.
- No `ReferenceError` is thrown for any non-assignment-target `this` in array position.

**Reproduction**
```
[this, u = u - 1];  // ReferenceError thrown, or u not decremented correctly.
```

**Suspected Cause**
In `parser_parse_array_literal`, after parsing an element, the parser may leave an opcode like `CBC_PUSH_THIS_LITERAL` in `last_cbc_opcode`. When a comma or the next element is processed, `parser_append_binary_single_assignment_token` and `parser_append_binary_token` may incorrectly try to convert that opcode (e.g., thinking it is an identifier) and produce invalid bytecode or throw a reference error. The `this` opcode should simply be flushed without any further mutation.

**Ask**
- Modify array literal parsing so that after parsing each element expression (inside the comma loop), if the last opcode is `CBC_PUSH_THIS`, it is immediately flushed (committed to the bytecode stream) and not left to be reinterpreted.
- Adjust the handling in `parser_append_binary_single_assignment_token` and `parser_append_binary_token` so that `CBC_PUSH_THIS_LITERAL` is always converted to a plain `CBC_PUSH_THIS` and flushed, regardless of the associated literal type, without emitting a `CBC_EXT_THROW_REFERENCE_ERROR` for non-identifier literals.
- Ensure that `parser_check_invalid_assign` is only called when the literal type is definitely `LEXER_IDENT_LITERAL` (add an assertion), to prevent misuse when called with `this`.

**Constraints**
- Must not introduce new syntax errors for valid ES5.1/ES2015 array literal constructs.
- Bytecode size and execution speed should not regress beyond a negligible margin.
- The fix must preserve correct behavior for strict mode (`this` can still be `undefined` depending on context).

**Affected files**
- `jerry-core/parser/js/js-parser-expr.c` (functions: `parser_parse_array_literal`, `parser_append_binary_single_assignment_token`, `parser_append_binary_token`, `parser_check_invalid_assign`).

CBC_PUSH_THIS should not be mutated in array literal parsing. (#3652)


As an ES2015 compliance issue, arrow functions and `yield` expressions should only be allowed in assignment expression positions, not as arbitrary operands. Currently, the parser treats arrow functions like any other primary expression, which results in invalid code like `3 + x => 3`, `x => {} = 1`, and `!x => 4` being accepted. The expected behavior is that such constructs produce a syntax error, because an arrow function (`=>`) must appear as an `AssignmentExpression`, not after a binary operator or in other expression contexts.

We need to:
- Add a validation step before parsing an arrow function (including its parenthesized parameter list) to ensure the current parser state represents an assignment expression context. If not, throw a `SyntaxError` with a message along the lines of “Unexpected arrow function or yield expression (parentheses around the expression may help).”
- After successfully parsing an arrow function, the parser should stop processing further binary operators and treat the arrow as the end of the expression, except when the next token is a comma or a closing parenthesis (i.e., when the arrow is part of a list). This prevents constructs like `x => {} (4)` or `x => {} a = 1` from being parsed incorrectly.
- Ensure the same restriction applies to `yield` expressions if they appear outside of a generator context that would allow them.
- Adjust the expression parsing loop to break out when an arrow function has been consumed, ensuring that trailing tokens do not get incorrectly incorporated into the same expression.

The implementation should be contained in the parser (`js-parser-expr.c`), with a new error code (`PARSER_ERR_ASSIGNMENT_EXPECTED`) and the corresponding error message. The unary expression parser should return a status indicating whether the expression ended with an arrow function that terminates further expression parsing.

Arrow functions should be parsed as assignment expressions. (#3336)


**Feature Request: Implement ES2015 `@@hasInstance` (Symbol.hasInstance) for the `instanceof` operator**

When the engine is built with ES2015 symbol support enabled (`JERRY_ES2015_BUILTIN_SYMBOL`), the `instanceof` operator must follow the ES2015 spec for `@@hasInstance`:

### Behavior

For an expression `x instanceof C`:

1. If `C` is not an object, throw a `TypeError` (no change to existing behavior).
2. If `C` is an object, retrieve `C[Symbol.hasInstance]`:
   - If the property access throws, propagate the exception immediately.
   - If the value is `undefined`, proceed with the ordinary `[[HasInstance]]` fallback (see below).
   - If the value is **not** `undefined` and **not callable**, throw a `TypeError`.
   - If the value is callable, call it with `x` as the sole argument, using `C` as the `this` value. Convert the result to boolean via ToBoolean, and return that boolean.
   - If the call throws, propagate the exception.
3. **Ordinary fallback** (when `Symbol.hasInstance` is `undefined`, not present, or the engine is built without ES2015 symbol support):
   - If `C` is not a function, throw a `TypeError`.
   - Otherwise, return `true` if `C.prototype` appears in `x`’s prototype chain, `false` otherwise. If `x` is not an object, throw a `TypeError`.

### Constraints & Edge Cases

- The custom `@@hasInstance` method receives the **left-hand side value as-is**, even if it is a primitive. No TypeError is thrown for a primitive left operand when `@@hasInstance` is used.
- The `this` binding inside the method must be the **constructor object** itself.
- Property access for `Symbol.hasInstance` may be defined via an accessor (getter); any exception thrown during the getter must be propagated.
- If `Symbol.hasInstance` exists but is not a function (e.g., a number, string, object), a `TypeError` must be thrown before attempting to call it.
- The return value of the custom method must be coerced to boolean using the standard ToBoolean abstract operation (truthy/falsy).
- All error cases (exception from getter, exception from call, non-callable method) must propagate the appropriate error without falling through to the ordinary instance check.
- The implementation must not leak memory from intermediate values (e.g., the retrieved method, the call result) and must handle them correctly per the engine’s value lifetime rules.
- The existing behavior for `instanceof` without symbol support remains unchanged.

Add @@hasInstance Symbol support for instanceof operator (#3226)


The `ArrayBuffer` constructor’s length argument conversion leaks the intermediate ECMA value and does not propagate errors from `ToNumber`. Invalid size arguments (non‑integral numbers, strings that convert to `NaN`, objects lacking a proper `valueOf`) either crash or produce garbage instead of reliably throwing `RangeError`.

**Expected behaviour**
1. The argument is converted to a number using the standard `ECMA_OP_TO_NUMBER_TRY_CATCH` / `ECMA_OP_TO_NUMBER_FINALIZE` pattern so that:
   - the temporary value returned by `ecma_op_to_number` is always freed,
   - any exception thrown during `ToNumber` (e.g., a `TypeError` for a Symbol) is returned to the caller.
2. After a successful conversion, if the number is not exactly equal to its `uint32` truncation (`num != (ecma_number_t)(uint32_t)num`), the constructor must throw `RangeError`. This covers non‑integral numbers, `Infinity`, `NaN`, and objects that resolve to such values.
3. Valid integral lengths (including numeric strings that represent integers) continue to work without error and without leaking.

**Current problem**
In `ecma_op_create_arraybuffer_object` the code directly calls
`ecma_number_t num = ecma_get_number_from_value(ecma_op_to_number(arg));`
without ever freeing the result, and without checking whether the call succeeded. A subsequent length check is present but may operate on a poisoned value after a failed conversion, leading to undefined behaviour or crashes.

Please fix the conversion and error handling to comply with the above, and ensure that the existing `RangeError` check is guarded by a successful conversion.

Fix unchecked size number conversion in ArrayBuffer (#1479)


We need a built-in `assert` mechanism that terminates execution immediately with a non-zero exit code when the asserted condition is false. Currently, tests rely on an `assertEquals` helper, but that is not available in standalone scripts and requires a runtime library. An intrinsic `assert` will allow direct boolean assertions anywhere without depending on external functions.

## Requested behavior

- The identifier `assert` shall be treated as a compile-time intrinsic, not a regular function call.
- `assert` must accept exactly one argument: an expression that evaluates to a boolean.
- If the argument evaluates to `true`, execution continues to the next statement.
- If the argument evaluates to `false`, the runtime must abort immediately with exit code `1` (a fatal error).
- Any attempt to call `assert` with zero arguments or with more than one argument must result in a parse-time error.
- `assert` is not available as a constructor; `new assert(...)` is not allowed.
- The intrinsic shall be recognized directly by the parser, without being defined in the global object, so that the bytecode is inlined as a conditional jump + `exitval` opcode pair.

## Design constraints

- The intrinsic lookup shall happen in `parse_argument_list` when the argument list type is `AL_CALL_EXPR`. If the callee is identified as an intrinsic, the parser must not generate a variable temporary for the result, and must not emit a `call_1` or `call_n` opcode. Instead, it shall emit a pattern equivalent to:
  - `is_true_jmp` to the instruction after a following `exitval 1`
  - `exitval 1`
- The `is_intrinsic` check shall compare the callee’s identifier string against a known list of intrinsics. Initially, only `"assert"` is supported.
- The argument count must be validated against the intrinsic’s expected count. A mismatch must raise `ERR_PARSER`.
- The existing `rewritable_opcodes` and temporary name logic should not be affected by intrinsics (intrinsics produce no lhs temporary).

## Pretty-printing

- The opcode pretty-printer should display the bytecode for `assert` clearly, maintaining consistency with existing conditional jump formatting. (Minimal changes: adjust `is_false_jmp` to print "== false" instead of "!" for readability, and ensure assignment-like opcodes print value types when available.)
- The pretty-printer must correctly handle the new intrinsic pattern without crashing on unknown opcode forms.

## Acceptance criteria

- A script containing `assert(true);` executes without error.
- A script containing `assert(false);` exits with status 1 and does not execute any subsequent statements.
- `assert(expr);` works inside any expression context where a statement is allowed.
- `assert()` and `assert(a, b)` produce parse errors.
- The expression `new assert(true)` remains a normal constructor call on whatever `assert` resolves to at runtime (i.e., the intrinsic only applies to direct calls, not `new` expressions).


We need to implement `Function.prototype.bind` as specified in ECMA-262 5.1 §15.3.4.5 so that user code can create bound function objects with preset `this` and arguments.

## Requirements

1. **New bound function object type**
   - Introduce an `ECMA_OBJECT_TYPE_BOUND_FUNCTION` object type.
   - Three internal properties must be stored on the bound function:
     - `[[TargetFunction]]` – the original callable.
     - `[[BoundThis]]` – the fixed `this` value (or `undefined` if no arguments).
     - `[[BoundArgs]]` – a list of the pre-bound arguments (beyond the first argument) stored as a collection.

2. **`bind` method behavior**
   - `Function.prototype.bind(thisArg [, arg1 [, arg2 …]])` must:
     - Throw a `TypeError` if `this` is not callable.
     - Create a new bound function object whose `[[Prototype]]` is `Function.prototype` (initial simplification; we may later align with the spec’s requirement to use the target’s `prototype` property).
     - Set the bound function’s `"length"` data property to `0`, non-writable, non-enumerable, non-configurable.
     - Thrower accessor properties for `"caller"` and `"arguments"` as described in the spec (throw on get/set).

3. **`[[Call]]` internal method**
   - When a bound function is called, it must:
     - Retrieve `[[TargetFunction]]` and `[[BoundThis]]`.
     - Merge `[[BoundArgs]]` with the call-time arguments (bound args first).
     - Invoke `[[Call]]` on the target with the merged arguments and the bound this value.

4. **`[[Construct]]` internal method**
   - When a bound function is used with `new`, it must:
     - Retrieve `[[TargetFunction]]`.
     - If the target is not a constructor, throw a `TypeError`.
     - Merge bound args with call-time arguments.
     - Delegate to `[[Construct]]` on the target with the merged arguments.

5. **`[[HasInstance]]`**
   - Delegate `instanceof` to the target function’s `[[HasInstance]]`.

6. **Garbage collector and memory management**
   - The new internal properties must be correctly marked during GC and freed when the bound function is reclaimed.
   - In particular, `[[BoundArgs]]` holds a collection that needs proper teardown.

## Acceptance criteria (observable behavior)

- `bind` returns a callable object whose `typeof` is `"function"`.
- Calling the bound function with additional arguments applies the bound `this` and prepends the bound arguments.
- Constructing a bound function whose target is not a constructor throws `TypeError`.
- A bound function constructed with `new` behaves like the target constructor but with bound arguments prepended; instances pass `instanceof` for the target and for the bound function.
- Bound functions do **not** have a `prototype` property.
- `bind` on a non-callable throws `TypeError`.

This ticket covers only the core logic of `bind`. The initial `length` can be left at `0`; fine-tuning to `max(target.length – boundArgs.length, 0)` can be done later if needed.


Fix TypedArray slice fastpath when constructor species returns a same-buffer view with a non‑zero byte offset and identical element type.

- Currently, when the source and target TypedArrays are the same element type (`info_p->id == new_typedarray_info.id`), the fastpath performs a single `memcpy` from the source buffer region to the target buffer region.
- This is incorrect when the target view has a non‑zero `offset` **and** the underlying `ArrayBuffer` is the same (i.e. the copy regions overlap). The `memcpy` can produce corrupted data.
- The fastpath must detect overlapping same‑buffer copies and copy element‑by‑element when `offset != 0`, ensuring correct results even when source and destination overlap. When `offset == 0` the existing `memcpy` is safe and should remain unchanged.

Fix Typedarray.slice fastpath when the content type is matching (#5177)


**Title**: `jerryx_arg_transform_optional` does not advance the JS argument iterator when the optional argument is `undefined`, causing misalignment of subsequent argument transformations

**Description**
When a function argument is marked optional (via `JERRYX_ARG_OPTIONAL`) and the corresponding JavaScript value is `undefined`, the helper `jerryx_arg_transform_optional` returns immediately without advancing the internal argument iterator. As a result, the iterator’s current position stays on the same `undefined` argument. The next argument transform then sees the same `undefined` value rather than the next user-supplied argument, leading to completely wrong behavior when more than one optional argument is used, or when a required argument follows an optional one.

**Steps to reproduce**
1. Define a native handler that uses `jerryx_arg_transform_this_and_args` with a mapping of two optional booleans (e.g., each created with `jerryx_arg_boolean(&flag, JERRYX_ARG_COERCE, JERRYX_ARG_OPTIONAL)`).
2. Register the handler as a JavaScript function.
3. Call the function from JS supplying only one argument, e.g., `func(true)`.
4. Observe that the *second* boolean is also set to `true` (the value of the first argument) instead of remaining its default (`false`), because the iterator did not advance past the missing second argument.

**Expected behavior**
When `jerryx_arg_transform_optional` encounters `undefined`, it should still advance the iterator (by calling `jerryx_arg_js_iterator_pop`), so that the omitted argument is consumed and subsequent transforms start from the next JS argument. The second optional parameter should remain unchanged (its default) when no corresponding JS argument is provided.

**Impact**
Any use of multiple optional arguments, or an optional argument followed by another mandatory/optional argument, is broken. Argument values get shifted, potentially crashing or producing incorrect results. Functions that rely on the default values of trailing optional arguments will read wrong data, and functions mixing optional and required parameters may misinterpret required parameters as missing.

**Suggested fix**
In `jerryx_arg_transform_optional`, replace the direct return of the `undefined` value with a call to `jerryx_arg_js_iterator_pop(js_arg_iter_p)`. This properly advances the iterator while still signalling that the argument was optional.

Optional arguments should advance the iterator in jerryx_arg_transform_optional (#2962)


Fix arrow function parsing: defer the lexer token consumption until after the parser context is restored. In `parser_parse_arrow_function`, the current handling of block bodies (and potentially expression bodies) calls `lexer_next_token` immediately after consuming the final `}` or expression, which occurs before `parser_restore_context`. This means the next token is read while the parser is still in the arrow function’s temporary context. The token must instead be consumed after `parser_restore_context`, otherwise tokens that depend on the surrounding context (especially `await`, `class`, and other context-sensitive keywords) are misparsed, leading to spurious syntax errors for valid programs. Move `lexer_next_token` after the `parser_restore_context` call, and only when the arrow function body is a block (since an expression body doesn’t consume a closing brace token). Ensure the logic still correctly handles the case where the arrow function has a non-block expression body (no deferred token advance needed).


**Title:** Allow disabling automatic index merges by setting `MaxAutoMergeIndexLevel` to 0

**Background**
The index uses an `MaxAutoMergeIndexLevel` setting to control up to which level tables are automatically merged. Currently, even if the level is set very low, automatic merges may still occur for levels at or above that value. Operators who want full manual control over index compaction have no clean way to opt out of all automatic merging.

**Request**
Support a value of **0** for `MaxAutoMergeIndexLevel` that completely disables automatic index merging. When this value is set:

- The index must **never** trigger an automatic merge (regardless of how many tables accumulate).
- All merging becomes manual-only. Existing manual-merge pathways remain responsible for compaction.
- When a manual merge is triggered, `GetTableForManualMerge` should return a table when there are **two or more** tables at level ≥ 0 (i.e., any time there are multiple tables in the whole index).
- `AddPTableForManualMerge` must skip the actual merge when only **one** table exists at levels ≥ 0, returning an empty deletion list and no new PTable.
- If multiple tables exist, manual merge should combine **all** tables into a single level-0 table, leaving no tables behind.

**Non‑obvious constraints / edge cases**
1. Reducing `MaxAutoMergeIndexLevel` from a non‑zero value to 0 while tables exist at higher levels must still work: those tables remain eligible for manual merge under the new “all tables” rule, and `GetTableForManualMerge` must correctly identify them.
2. When `MaxAutoMergeIndexLevel = 0`, manual merge must not attempt to merge zero tables—if only one table exists, `GetTableForManualMerge` must return `null` for the table, and the caller should treat it as a no‑op.
3. Index map file persistence already stores an integer for the max auto merge level; ensure that a value of 0 round‑trips correctly and is honored after restart.
4. Existing code that uses a low auto‑merge level (e.g., 5) for testing corrupt index entries should not be affected by this change in semantics. The test harness may need to use a value that effectively disables automatic merges (like `int.MaxValue`) to avoid interference from automatic compaction during those tests.

**Expected behavioral change**
- With `MaxAutoMergeIndexLevel = 0`, the index behaves as if automatic merging is disabled. Only manual merges (triggered externally) reduce the number of table files.
- Manual merge will now merge **all** tables, not just those above a certain level, when the auto‑merge level is 0.
- If a manual merge is requested and only one table exists, the operation does nothing—previously it might have tried to merge a single table unnecessarily.

Adds support for disabling automerging completely


Change default data and log directories to platform-appropriate paths instead of using OS temp directories.

- **Linux**: data must default to `/var/lib/eventstore`, logs to `/var/log/eventstore`.
- **Windows / macOS**: data must default to a `data` subdirectory of the installation/execution directory, logs to a `logs` subdirectory.
- Static content and configuration directories should also follow platform conventions: on Linux, `/usr/share/eventstore` and `/etc/eventstore` respectively; on Windows/macOS, the installation directory itself.
- Apply these defaults for both the cluster node and the test client, so that when no explicit `--db` or `--log` argument is provided, the correct platform path is used (no temporary path fallback).
- Ensure the behavior change does not break scenarios where paths are explicitly supplied; defaults must only apply when the user omits the corresponding option.

Change default log and data path based on platform


```markdown
### Title
Projection deletion: handle missing substreams, transient state cleanup, and race with persisted state write

### Background
When a projection is deleted, the system:
1. Deletes projection “substreams” (e.g. checkpoint, emitted streams).
2. Writes a final persisted state to the `$projection-<name>` stream.

These steps are independent and may overlap. Several defects have been observed:

- Deletion of projections that never created substreams (transient, or with no emitted events) fails because `DeleteStream` returns `WrongExpectedVersion` for non-existent streams.
- Transient projections leave an internal `_pendingWritePersistedState` flag set after their state is written, causing later operations to see stale state.
- A race can cause the final persisted state write to complete after substream deletion, leading to multiple `ProjectionManagementMessage.Internal.Deleted` messages being published.
- The interlocked decrement and condition check on `NumberOfPrequisitesMetForDeletion` is not atomic; a multi-threaded caller could act on a stale value.

### Requested Changes

1. **Treat `WrongExpectedVersion` as successful deletion for projection substreams**
   In `DeleteProjectionStreams()` and `EmittedStreamsDeleter`, when deleting checkpoint/emitted/state streams, if the delete result is `WrongExpectedVersion` the stream did not exist. This should be considered a success (with an informational log) rather than an error or unhandled case. Deletion should proceed to the next step without failure.

2. **Reset `_pendingWritePersistedState` for transient projections**
   After completing a write of persisted state for a transient projection, the flag `_pendingWritePersistedState` must be set to `false`. Without this the flag can remain true and interfere with subsequent lifecycle transitions.

3. **Avoid duplicate `Internal.Deleted` messages**
   In `ManagedProjection.Reply()`, do not publish `Internal.Deleted` if a persisted state write is still pending (`_pendingWritePersistedState == true`). The event should be published only after the final state write completes and the `Deleted` flag is set.

4. **Atomic check in `DeleteIfConditionsAreMet`**
   Combine the `Interlocked.Decrement` and the `<= 0` check into a single atomic expression so that the condition is evaluated on the updated value exactly once, preventing possible race conditions.

5. **Backward compatibility note**
   External clients (TCP/gRPC/Web) may still receive `WrongExpectedVersion` when deleting individual streams directly, but internally subsystem cleanup must not fail or produce errors for non-existent streams.

### Acceptance Criteria
- Deleting a projection that has no checkpoint, emitted, or state streams completes without error.
- After deleting a transient projection, no stale `_pendingWritePersistedState` remains.
- Only a single `Internal.Deleted` event is published per projection deletion, regardless of timing between substream deletion and state writes.
- Concurrent callers to deletion readiness (`DeleteIfConditionsAreMet`) see a correct, thread-safe countdown.
```

fixed errors while deleting projections without substreams


### [DEV-1625] Enforce Unicode NFC Normalization on Schema Names

**Context**
Schema names are accepted in Unicode, but the system currently accepts any valid sequence of the allowed character set without checking Unicode normalization. This can cause equivalent names in different normalization forms (e.g., NFC vs NFD) to be treated as distinct, leading to duplicate schemas, lookup failures, and confusion. For example, `café` (precomposed) and `café` (with a combining accent) are visually identical but may be stored as separate schemas.

**Change required**
- The validators for schema names (both in the HTTP API v2 streams module and the gRPC Schema Registry) must reject any name that is not in Unicode NFC (Normalization Form C).
- The existing character-set validation must remain in place.
- Error messages should clearly state that the name must be in Unicode NFC normalization form.
- The `GetSchemaRequestValidator` in the Schema Registry currently only validates non‑emptiness; it must delegate to the shared `SchemaNameValidator` instead so the normalization check is consistently enforced for `GetSchema` requests as well.

**Affected components**
- `KurrentDB.Api.Streams.Validators.SchemaNameValidator`
- `KurrentDB.SchemaRegistry.SchemaNameValidator` (and all request validators that reference it, including `GetSchemaRequestValidator`)
- The corresponding configuration of error messages in both modules.

**Acceptance criteria**
- A schema name already in NFC is accepted.
- A schema name that is not in NFC (e.g., NFD representation of the same text) is rejected with a validation error mentioning the NFC requirement.
- An empty schema name is still rejected with an appropriate message.

[DEV-1625] Require Unicode NFC normalization for schema names (#5603)


**Title:** Reject invalid user index creation requests and improve field validation messages

**Background**
The gRPC `CreateIndex` endpoint currently accepts requests that cannot produce a working index or that are misconfigured in ways that the backend will eventually reject. This leads to confusing failures later, rather than early validation feedback.

**Requirements**

1. **Require at least a filter or a field**
   A `CreateIndexRequest` with an empty/whitespace `Filter` string and zero `Fields` must be rejected with an appropriate validation error message (e.g. “At least a filter or a field must be provided”).

2. **Disallow empty field selectors**
   When a field is included in the `Fields` list, its `Selector` must be a valid JavaScript function with exactly one argument. An empty string is no longer permitted as a valid selector. Update the error message accordingly (from the current “...must be empty or a valid JavaScript function…” to simply “Field selector must be a valid JavaScript function with exactly one argument”).

3. **Clarify field‑type error wording**
   The error message for an unspecified field type (`IndexFieldType.Unspecified`) should be changed from “Field type must not be unspecified” to “Field type must be specified”, making it clearer and less awkward.

**Edge cases / constraints**
- A `Filter` that is non‑empty but consists only of whitespace should still be considered “empty” for the purpose of rule 1.
- The field‑selector validation applies independently to each `IndexField` in the `Fields` list.
- All existing validation for filter syntax, index name, and field name must remain unchanged.

**Acceptance criteria**
- Calling `CreateIndex` with no filter and an empty `Fields` list returns `InvalidArgument` with the message “At least a filter or a field must be provided”.
- Calling `CreateIndex` with a field whose `Selector` is an empty string returns `InvalidArgument` with “Field selector must be a valid JavaScript function with exactly one argument”.
- Calling `CreateIndex` with a field whose `Type` is `INDEX_FIELD_TYPE_UNSPECIFIED` returns `InvalidArgument` with “Field type must be specified”.

[DB-1838] Fix validation when creating a user index (#5448)


# Persistent Subscription: Allow consumer strategies to skip events and reorder retries by event number

## Context
The current `StreamBuffer` uses `TryDequeue`/`TryPeek` to hand messages to the subscription loop. This forces a consumer strategy to either accept a message (removing it from the buffer) or reject it because of “no capacity” – there is no way to leave a message in the buffer for later delivery.
Additionally, retried messages are just queued in the order they are retried, ignoring the original event number. This can cause out-of-order replay when multiple events are nacked and retried.

## Requested changes

### 1. Scanning-based consumption with explicit marking
Replace `TryDequeue` and `TryPeek` on `StreamBuffer` with an iteration mechanism that does **not** remove messages automatically.
- Introduce a method (e.g., `Scan()`) that yields “pointers” to outstanding messages.
- Each pointer provides read-only access to the message and a `MarkSent()` operation that removes it from the buffer.
- `MarkSent()` **must** throw if called more than once on the same pointer (the underlying node is already removed).
- The iteration order must be: all retried messages first, followed by buffered read messages.
- The enumeration must work safely even when earlier yielded elements are marked as sent during iteration (e.g., by copying the next node before yielding). It should assume no *new* messages are added to either buffer while iterating.

### 2. Ordered retried messages
Modify `AddRetry` so that retried events are inserted into the retry buffer in **ascending order of event number** (the event number of the event or link).
- Use a stable insertion, i.e., for equal event numbers preserve the order of `AddRetry` calls.
- This guarantees that when a batch of nacked events is retried, they are replayed as close to the original stream order as possible (retried events still come before any read-buffer events).

### 3. New consumer strategy result: `Skipped`
Extend the `ConsumerPushResult` enum with a `Skipped` value.
When a consumer strategy returns `Skipped`, the subscription **must not** mark the message as sent, effectively leaving it in the buffer for future delivery attempts.

### 4. Update subscription delivery loop
Modify `PersistentSubscription.TryPushingMessagesToClients` to use the new scan:
- Iterate through the scan results.
- If a strategy returns `Sent`, call `MarkSent()` on the pointer and update the last known message position.
- If it returns `Skipped`, do **nothing** with that message; continue to the next pointer.
- If it returns `NoMoreCapacity`, break out of the loop immediately.

Any other internal consumer that currently dequeues messages (e.g., `GetNextNOrLessMessages`) should also adopt the scan-and-mark pattern and respect the new `Skipped` semantics where applicable.

### 5. Cleanup
Remove the now-unused `TryDequeue`/`TryPeek` methods and the `WTFException` class to prevent them from being used by mistake.

## Invariants & edge cases
- A skipped message must stay in the buffer; `BufferCount` should reflect that.
- A message may be marked sent **at most once**; a second `MarkSent` call must raise an error.
- The scan must never expose a message that was already marked sent during the same scan.
- Retried messages appear in strictly increasing (or equal) event-number order, always before any read-buffer messages.
- The retry buffer’s `GetLowestRetry()` must continue to return the minimum event number across retried messages.

New features for the persistent subscription StreamBuffer:


**Ticket: Fix `GetAllUsers` after account deletion & enforce expected version in test harness**

- **Background**
  - The `TestFixtureWithExistingEvents` helper (used by user-management tests) unconditionally accepts all write requests regardless of the caller-supplied `ExpectedVersion`.
  - The `AllUsersReader.Run` → `ReadUserDetailsBackwardCompleted` path does not handle `ReadStreamResult.StreamDeleted`. When a previously deleted user stream is encountered, the reader falls through to the `default` branch and aborts the whole operation, making `GetAllUsers` return an error.

- **Behavior to implement**
  1. **Expected‑version enforcement in `TestFixtureWithExistingEvents`**
     Inside `ProcessWrite`, when `message.ExpectedVersion` is not `Any`, verify that it matches the current stream length (i.e., `list.Count - 1`). If it does not, reply immediately with `WriteEventsCompleted` carrying `OperationResult.WrongExpectedVersion` and do not append the events. This is needed so tests can properly simulate concurrency conflicts (e.g., creating a user that already exists).

  2. **Handle `StreamDeleted` gracefully in `AllUsersReader`**
     In the switch inside `ReadUserDetailsBackwardCompleted`, treat `ReadStreamResult.StreamDeleted` as a “skip” case: do nothing (do not try to load user details, do not abort). The reader should continue processing remaining users and complete successfully, returning only non-deleted accounts.

- **Acceptance criteria**
  - Calling `GetAllUsers` when one or more user account streams have been deleted returns the existing users without error.
  - The test helper rejects writes with an incorrect expected version, and corresponding user-management tests (e.g., creating a duplicate user) can assert a `Conflict` result.
  - Existing tests continue to pass, and the `when_getting_all_users` test class (currently misspelled `when_getting_all_iusers` – purely a cosmetic mis‑name) should still cover the scenario with deleted users once the typo is corrected.

- **Files likely affected**
  - `src/EventStore/EventStore.Core.Tests/Helper/TestFixtureWithExistingEvents.cs`
  - `src/EventStore/EventStore.Core/Services/UserManagement/AllUsersReader.cs`
  - `src/EventStore/EventStore.Core.Tests/Services/UserManagementService/user_management_service.cs` (new test fixture for duplicate user creation)

Fixed: deleted user accounts break get all users


The HTTP transport layer currently converts the entire request body into a UTF‑8 string before passing it to handlers. This causes two observable problems:

1. **XML requests with a leading BOM are rejected.**
   When a client sends an XML write‑request that starts with the UTF‑8 byte order mark (`0xEF 0xBB 0xBF`), the automatic event converter fails to parse the body correctly. The BOM is either lost or causes `XDocument.Parse` to throw an exception, resulting in a 400 or 500 error.

2. **Binary-safe processing is impossible.**
   There is no way for a handler to access the raw bytes of a request body. Any content that is not valid UTF‑8 (or that the caller needs to process without interpretation) is mangled by the premature string conversion.

We should change the HTTP entity management layer to deliver the request body as a **raw byte array**.

**Acceptance criteria**

- When an HTTP request arrives, the `HttpEntityManager` must provide the entire body as a `byte[]` that is exactly the length of the stream (no padding with zero bytes from an oversized buffer).
- A new overload of `ReadRequestAsync` must accept a callback with the signature `Action<HttpEntityManager, byte[]>`. The existing string‑based overload must remain and must work by converting the byte array to a UTF‑8 string (preserving existing behavior).
- The automatic event converter (`AutoEventConverter`) used by the Atom controller must accept the body as a byte array and parse it correctly:
  - XML bodies that begin with the UTF‑8 BOM must be parsed successfully, as if the BOM were absent.
  - JSON bodies must continue to work exactly as before, with no change in parsing semantics.
- Posting an event using XML that includes a BOM must result in the event being stored correctly, with the data and metadata fields handled according to the existing conversion rules.
- The change must not affect the outward wire‑format of XML responses produced by the server; any internal serialisation changes (e.g., switching from `XmlTextWriter` to stream‑based serialization) must not alter the response body or introduce a BOM where previously there was none.

Added ability to receive byte[] as HTTP request.


The `TFChunkChaser` (used to feed committed records to the reader index) must correctly traverse transaction-file chunks that have been scavenged – that is, where some log records have been physically removed. Currently it may fail to skip removed records, leading to gaps, crashes, or incorrect reads when chunks contain scavenged content.

**Acceptance criteria**

1. **Forward traversal after scavenging**
   Given a database composed of multiple chunks where a scavenge removed a subset of records (e.g. all records with even-or odd-numbered positions), starting a chaser from position 0 reads *every surviving record* in order, without errors, until the writer checkpoint provided at chaser construction is reached.

2. **Backward traversal after scavenging**
   Starting a chaser from the writer checkpoint and reading backwards yields the same set of surviving records in reverse order, with no omissions or duplicates.

3. **Forward/backward turn-around**
   After reading forward through all surviving records, the chaser can immediately read backward through the same records without missing or reordering any.

4. **Start from arbitrary position**
   When the chaser begins reading forward (or backward) from *any* logical position – including a position that originally belonged to a removed record – it correctly seeks to the next (or previous) surviving record and continues without interruption.

5. **Writer checkpoint boundary**
   The chaser must not read past the writer checkpoint instance it was initialized with, even if the underlying database’s global writer checkpoint has moved further ahead. The chaser stops exactly at that boundary.

6. **Chaser position update**
   After each successful read the chaser’s exposed `Position` reflects the location of the *next* record to be read, and its associated chaser checkpoint is advanced accordingly.

7. **Chunk-boundary safety**
   The chaser handles scenarios where surviving records span chunk boundaries, and where a chunk boundary follows a scavenged record, without null-reference or out-of-range exceptions.

TFChunkChaser now uses TFChunkSequentialReader internally. Added more tests for traversing scavenged chunks.


**Request**: Multi-stream event distribution point must deliver committed events in global prepare-position order during catch-up, rather than in the order read-completions arrive.

**Background**
When a projection goes through catch-up with a multi-stream reader, events from different streams are currently forwarded to the projection in the order the `ReadStreamEventsForwardCompleted` responses are received. This can cause events to appear out-of-order relative to their actual commit order in the transaction log, leading to incorrect projection state.

**Desired behaviour**
1. **Ordering by prepare position**
   Across all streams managed by the multi-stream reader, the `CommittedEventDistributed` messages must be published in ascending order of the prepare position (`LogPosition`) of the event (or its link-to target).
   If a read response delivers multiple events from one stream, they are still emitted in the correct interleaved order with events from other streams based on their prepare positions.

2. **Safe join position delivery**
   The safe transaction-file reader join position (`SafeTransactionFileReaderJoinPosition`) embedded in the `CommittedEventDistributed` messages must reflect the minimum of the last known prepare positions across all streams.
   This safe position must only be advanced (and a dedicated “end-of-buffer” `CommittedEventDistributed` sent) once all pending events with a prepare position less than or equal to that safe position have been delivered.
   If there are no pending events, the safe position delivery can happen immediately after a read-completion that advances it.

3. **End-of-stream handling**
   When a stream reaches its end (an empty events array in a successful read completion), its last commit position is used to update the safe join position, and it must signal that no further events will come from that stream. Any remaining buffered events from other streams up to the new safe position should be delivered, followed by a safe-position message.

4. **No premature delivery**
   Until at least one read completion has arrived for each configured stream, no `CommittedEventDistributed` messages shall be published for events. This prevents a projection from seeing events from one stream before the relative ordering with other streams can be determined.

5. **Respect pause/resume**
   After delivering all events up to the current safe position (or after ending all streams), the distribution point must not request further events from any stream while paused is requested. When resumed, it must continue from the last delivered event numbers on each stream.

**Non-goals / unchanged behaviour**
- Link-to resolution and event metadata propagation remain as before.
- The read-request cycle (tick messages, delays, max read count) is unchanged except for the ordering constraint.

**Constraints**
- Must not break projections that use a single stream (ordering is trivially satisfied).
- Must not degrade performance significantly; buffering should only retain events that cannot yet be delivered due to ordering uncertainty.

**Acceptance Criteria**
- Given two streams `a` and `b`, with events at prepare positions 50 and 100 on `a`, and 150 on `b`, when all reads complete, the projection receives events in order: `a:50`, `a:100`, `b:150`.
- Given one stream with events and one stream that returns `NoStream`, the events from the first stream are delivered immediately, with the safe position advanced to the last commit position of the no-stream stream.
- Given both streams eventually return empty read completions (end of stream), after delivering all buffered events a final safe-position message is emitted with the highest last commit position among the streams.

Event ordered by prepare position when projection is catching-up with multi-stream-reader event distribution point


When subscribing to `$all` over gRPC, clients may receive events out of order or miss events entirely, particularly when the subscription transitions from reading historical events to live processing.  The current implementation can also terminate the entire subscription with a `Consumer too slow` error if the client cannot consume live events fast enough, forcing a manual resubscription and leaving a gap that is not automatically filled.

**Expected behavior**

- Events are always delivered in ascending `$all` position order, from the requested starting point through the live head and then onward.
- If the live event buffer fills (e.g. because the client is slow), the subscription should gracefully fall back to index‑based catch‑up reads to cover any missed events, and later resume live delivery once the client has caught up again.  No events should be dropped, and the subscription must not be terminated due to back‑pressure.
- The client should be explicitly notified when the subscription has reached the live head (`SubscriptionCaughtUp`) and again when it temporarily leaves live mode to catch up (`SubscriptionFellBehind`), so the client can observe the internal state.

**Current behaviour / observations**

- The `AllSubscription` enumerator uses a race between a catch‑up page loop and an unbounded live event channel.  This can cause live events to be delivered ahead of catch‑up events that were still being read, leading to out‑of‑order delivery.
- When the live event channel becomes full, the subscription is cancelled with a timeout error and the client must resubscribe from scratch – it cannot simply recover and continue.
- Sequential event numbers on the live channel are not verified, so a gap caused by a dropped live event (due to a full channel) goes undetected, resulting in silent event loss.

**Impact**

This makes `$all` subscriptions unreliable for any workload where the consumer occasionally falls behind, such as rebuilds of read models or replication feeds.  Clients are forced to implement complex resubscription logic and still risk missing events.

gRPC $all subscriptions with smooth transitions between live and catchup


- Support `linkMetadata` in projection JavaScript handlers: when a projection processes a `$>` (link-to) event, make the link event’s own metadata available to the script as `e.linkMetadata` (expose `ResolvedEvent.PositionMetadata`).
- In the event stream reading helpers (`TestFixtureWithExistingEvents`), correct the computation of `nextEventNumber`, `lastEventNumber`, and `isEndOfStream` when reading streams that contain resolved links – use the original event number (from `OriginalEvent`) rather than the resolved event number to get proper navigation and end-of-stream detection.
- In `V8ProjectionStateHandler`, guard against null `PositionMetadata` and `Metadata` by converting to empty string where missing, so projection scripts don’t encounter exceptions when metadata is absent.
- Expose `outputState` from the prelude (`1Prelude.js`) so scripts can directly use `outputState()` to emit the projection result.
- Add tests that verify link metadata is correctly passed (matching the link’s body) and that the projection result stream contains the expected output, ignoring the terminal `$eof` event when checking the last data event.


Implement `SpoolStreamReading` for the parallel-query master phase so catalog events are distributed to slave projections.

- `ParallelQueryMasterProjectionProcessingPhase.Handle(CommittedEventReceived)` currently throws `NotImplementedException`. Change it to extract the referenced stream id from the received catalog event and publish a `ReaderSubscriptionManagement.SpoolStreamReading` to a slave projection.
- Use the slave projection communication channels assigned via `AssignSlaves`. For now, always forward to the first channel in the `"slave"` group; proper load distribution will come later.
- Extract the target stream id using the same logic that `ByStreamCatalogEventReader` uses for `$@`, `$>`, `$stream-created`, etc. Move that logic into a shared helper on `SystemEventTypes` so both places stay in sync and new event types are handled in one spot.
- The forwarded `SpoolStreamReading` must include the stream id from the event, the slave’s `CoreProjectionId`, and a placeholder stream sequence number (use `-1` until real tracking is added).
- Only published catalog events that pass the `_limitingCommitPosition` check in the catalog reader will reach the master phase; no additional filtering is required here.

Added: passing SpoolStreamReading request to a slave projection (the first one)


**Title:** Unhandled type conversion errors when parsing command-line arguments, config files, or environment variables

**Severity:** Medium
**Area:** Configuration Parsing (EventStoreOptions)

**Observed Behavior**
When a user provides an invalid value for a typed option (e.g., a non-numeric string like `"invalidformat"` for an integer property such as `-httpPort`), the application throws an unhandled exception and terminates with a confusing, low-level error. The exact exception type differs depending on the input source:

- **Command-line argument:** A `PowerArgs.ArgException` or `System.FormatException` is thrown directly, bypassing any custom error handling.
- **Configuration file (JSON):** A `Newtonsoft.Json.JsonReaderException` is thrown if the type does not match.
- **Environment variable:** A `System.FormatException` is thrown during `Convert.ChangeType`.

In all cases the exception message does not include the option name or value, making it very hard for users to identify the misconfiguration.

**Expected Behavior**
All type-mismatch errors (invalid format, deserialization failures, conversion failures) should be caught and re-thrown as a single, unified `OptionException`. The `OptionException` should contain a human-readable message that includes:

- The name of the option that failed (if known).
- The invalid value supplied.
- A hint that the value could not be converted to the expected type.

This ensures that:
1. The application can handle the error gracefully (e.g., display usage/help text) rather than crashing with a raw stack trace.
2. Users get immediate, actionable feedback about the specific misconfiguration.

**Impact**
Without consistent error handling, administrators and developers troubleshooting startup issues often waste time tracing stack traces from different exception types. A unified `OptionException` wrapping all underlying conversion errors would make configuration problems self-diagnosing and improve the overall user experience.

**Acceptance Criteria**
- When **command-line arguments** fail type parsing, catch the underlying exception (e.g., from `PowerArgs.Args.Parse`) and throw an `OptionException` with a descriptive message.
- When **JSON configuration files** fail deserialization due to type mismatches, catch the exception (e.g., `JsonReaderException`) and throw an `OptionException`.
- When **environment variables** fail conversion via `Convert.ChangeType`, catch the `FormatException` and throw an `OptionException`.
- In all cases, the original exception should not leak to the user; only the `OptionException` should be surfaced.
- The error messages should be consistent and include the option name/value where possible.

Added tests to ensure that we catch the type conversion errors from command line argument, environment variables or config files


**Title:** Unresolved link-to events missing position fields in HTTP/Atom API responses

**Context**
The HTTP/Atom API (used by the legacy admin UI and other consumers) returns event entries with an embed level that controls how much detail is included. When `EmbedLevel > Content` (Rich, Body, PrettyBody, TryHarder), entries are serialized as rich entry elements that include position fields (`positionEventNumber`, `positionStreamId`) and, when the event is a link, link metadata. The serialization is handled by `Convert.ToEntry`.

Currently, when a resolved event contains a link-to event that **failed to resolve** (e.g. the source stream was truncated by `$maxCount` or deleted), `Convert.ToEntry` skips creating the rich entry element entirely. That means `positionEventNumber` and `positionStreamId` are absent from the JSON response. The legacy AngularJS UI relies on these fields in `ng-repeat track-by`; duplicate `undefined` keys break tracking and cause all parked messages to be hidden.

**Expected Behavior**
When `embedContent > EmbedLevel.Content`, unresolved link-to events should still produce a `RichEntryElement` containing:
- `positionEventNumber` and `positionStreamId` populated from the link event itself (via `OriginalEvent`).
- Link metadata populated from the link event (when `embedContent >= EmbedLevel.Body`).

However, the *resolved* event fields (`eventId`, `eventType`, `eventNumber`, `streamId`, `data`) must **not** be populated when resolution failed — they should remain as their default/unset values.

When `embedContent <= EmbedLevel.Content`, unresolved links should continue to produce a plain entry element (no `RichEntryElement`), matching existing behavior.

The fix must not change the output for successfully-resolved links.

Populate position fields for unresolved link-to events in HTTP API (#5663)