**Title:** Tab completion fails or returns wrong results in multi-line cells

**Description**
When the user triggers tab completion inside a multi-line input (e.g., in the notebook or the Qt console) and the cursor is on any line other than the first, the completion either returns zero matches or matches from an incorrect namespace. The problem occurs because the kernel currently passes the *entire* multi-line code string to the IPython line-oriented completer, rather than isolating the single line that contains the cursor.

**Steps to reproduce**
1. Create a cell with at least two lines, for example:
   ```
   import os
   x = os.pa
   ```
2. Place the cursor right after `os.pa` on the second line and request tab completions.
3. Observe that the completion list is either empty or does not contain `os.path` etc.

**Expected behavior**
The kernel should extract only the line containing the cursor from the multi-line cell and pass *that line* (with the cursor position adjusted to be relative to the line’s start) to the underlying completer. The completion reply must still report `cursor_start` and `cursor_end` as absolute character offsets inside the full cell text, so the frontend can correctly highlight the match.

**Edge cases / constraints**
- If `cursor_pos` is `None` the cursor is considered to be at the very end of the cell.
- The line extraction must preserve the original line text exactly (including any trailing newline that `splitlines(True)` would keep) so that token offsets remain valid.
- The fix should not change completion behavior for single-line cells or for lines that are the first line of the cell.

**Impact**
This makes tab completion unreliable in any multi-line cell, which is a very common editing pattern (imports followed by code, multi-line function calls, etc.). The regression is especially noticeable in the IPython notebook and the Qt console where multi-line cells are the default workflow.


Add opcode handlers for strict equality (`===`) and strict inequality (`!==`).
Currently `equal_value_type` and `not_equal_value_type` are listed as unimplemented; implement them in the interpreter using a new ECMA operation `ecma_op_strict_equality_compare` that implements the Strict Equality Comparison Algorithm (ECMA-262 5.1, 11.9.6).

The opcodes must evaluate the left and right operands, perform the strict comparison, and set the destination variable to `true` or `false`.

The comparison operation must handle these cases:
- Different types ⇒ `false`
- `undefined` or `null` ⇒ `true` when both have the same type
- Number: NaN ⇒ `false` even when both operands are NaN; +0 and −0 considered equal
- String: exact character-by-character equality (same length, same characters in order)
- Boolean: both `true` or both `false`
- Object: same reference identity (compressed pointer equality)

The `not_equal_value_type` handler should simply negate the strict equality result.

Declare the new operation in `ecma-comparison.h` and implement it in `ecma-comparison.c`.

Add opfunc_equal_value_type and opfunc_not_equal_value_type opcode handlers. Add test.


**Bug Report: `%TypedArray%.from` is unimplemented and may crash; `%TypedArray%.of` returns `EMPTY` instead of `undefined`**

**Summary**
The static `from` method of typed array constructors (e.g. `Int16Array.from`, `Float32Array.from`) is a stub that returns an internal empty value.  Code that attempts to use it receives a useless result, and some invocations (e.g. calling `from` without arguments) trigger an internal crash instead of a proper `TypeError`.  Additionally, the static `of` method returns the same empty value rather than `undefined`, violating the specification’s requirement for an unimplemented optional extension to still be a valid function returning `undefined`.

**Steps to reproduce**
1. Call any typed array’s `from` method, e.g. `Int16Array.from([1,2,3])` – no typed array is created; the return value is effectively unusable.
2. Call `Int16Array.from()` with no arguments – the engine hits an internal assertion or crash instead of throwing a `TypeError`.
3. Call `Int16Array.of()` – the method returns an empty sentinel value instead of `undefined`.

**Expected behavior**
* `TypedArray.from` should be fully implemented according to ES2015 §22.2.2.1:
  - If `this` is not a constructor (specifically, not one of the typed array constructors), throw a `TypeError`.
  - If the first argument (`source`) is missing, throw a `TypeError`.
  - If a second argument `mapfn` is provided, it must be callable; otherwise throw a `TypeError`.
  - When `this` is a valid typed array constructor, construct a new typed array of the appropriate type, populating it by iterating the `source` (array-like or iterable), optionally applying `mapfn` with the given `thisArg`.
  - The resulting typed array should use the correct prototype, element size, and internal class name for each typed array variant (Int8, Uint8, Uint8Clamped, Int16, Uint16, Int32, Uint32, Float32, Float64).
* `TypedArray.of` should return `undefined` (its actual implementation remains TODO, but the stub must not produce an internal empty value).

**Impact**
Any script that relies on `TypedArray.from` to convert iterables/array-likes into typed arrays simply fails.  More critically, the missing argument check in the current stub leads to a crash, which can be triggered by untrusted content.  The incorrect return value from `of` can also confuse programs that test for `undefined`.  This prevents adoption of ES2015 typed array features and blocks related functionality.

Implement %TypedArray%.from and fix the issue #1670 (#1679)


**Title:** Compact Profile: Missing/unimplemented features cause fatal errors instead of throwing `CompactProfileError`

**Severity:** High
**Configuration:** `CONFIG_ECMA_COMPACT_PROFILE` enabled

**Observed behavior**
When the engine is built with the Compact Profile, several language features that are intentionally omitted still exist as stubs. Invoking them triggers `JERRY_UNIMPLEMENTED` assertions or internal fatal errors, leading to an immediate engine crash or undefined behaviour.

Examples of crashing scenarios:
- Calling `eval(...)`
- Using `new Function(...)` (the `Function` constructor)
- Any access to the `arguments` binding inside a function (e.g., `var a = arguments;` or `var arguments = 1;`)
- Invoking methods on built-in objects that are disabled under the profile, such as `Date.now()`, or trying to call `JSON` / `URIError` objects as functions

**Expected behavior**
Instead of asserting or crashing, the engine should throw a `CompactProfileError` exception in each of these cases. This is a dedicated built-in error that signals unsupported functionality. Throwing it would allow scripts to use `try/catch` to detect the unavailability of features and handle the situation gracefully, maintaining engine stability.

In detail:
- `ecma_builtin_global_object_eval` should return a throw completion containing `CompactProfileError`.
- `ecma_builtin_function_dispatch_construct` (for the `Function` constructor) should similarly return a throw completion with `CompactProfileError`.
- For the `arguments` binding: when a declarative lexical environment is queried or mutated for `arguments`, `has_binding` should return `true` (so that the binding appears to exist), but `get_binding_value` and `set_mutable_binding` should both throw `CompactProfileError`.
- Unsupported built-in properties that map to objects like `JSON` or `URIError` should be defined as accessor properties whose `[[Get]]` and `[[Set]]` are the `CompactProfileError` object, causing any invocation to throw.

**Impact**
Without this change, any script that accidentally or unknowingly touches a restricted API in Compact Profile will crash the engine, making it impractical to write defensive code or polyfills that fall back when features are absent. The required behavior aligns with the Compact Profile’s stated purpose: reduce footprint while providing predictable error handling for absent capabilities.

Throwing CompactProfileError in cases required by Compact Profile.


We need to ensure that built-in array methods which accept integer index arguments (e.g., `indexOf`, `lastIndexOf`, `fill`, `slice`, `copyWithin`) correctly handle cases where the coercion of those arguments – for instance through a `valueOf` function – side-effects the array’s length.

**Acceptance Criteria**

1. **Safe argument coercion for `indexOf` and `lastIndexOf`**
   - When the `fromIndex` argument is an object whose `valueOf` sets `array.length = 0`, the call must return `-1` without accessing any array element or causing an out-of-bounds memory operation.
   - When the coercion reduces `array.length` to a smaller positive number, the search must be bounded by the original `len` (as defined by the spec), but the implementation must not use a stale buffer pointer that could point to freed memory. The result should be `-1` if the target element is not found within the valid range.
   - When the coercion increases `array.length`, the search must still be restricted to the original length (no out-of-bounds reads) and return the expected index or `-1`.

2. **Safe argument coercion for `fill`**
   - If the `start` or `end` argument coercion (via `valueOf`) causes `array.length` to become `0`, the method must return the array unchanged (empty) without performing any element writes.
   - If the coercion modifies the length to a different value, the operation must respect the originally computed bounds but must never write beyond the actual backing store or beyond the original length.

3. **Safe argument coercion for `slice` and `copyWithin`**
   - The same robustness must apply to these methods when their index arguments cause length mutations during coercion: no crashes, no out-of-bounds access, and results must align with the ECMAScript specification’s length-at-call-time semantics.

4. **General invariants**
   - Throughout all these methods, the engine must never dereference a null or freed internal array buffer as a result of length changes triggered during argument coercion.
   - The implementation must not rely on length checks like `len != 0` that are computed before the coercion and may become invalid afterwards.
   - Edge case: an array that is initially non-empty but becomes empty (length 0) during coercion must be treated as empty for the remainder of the method execution.
   - Edge case: if the array's backing store is extended during coercion, the method must still only operate within the original bounds, avoiding access to uninitialised parts.

Fix length check for Array.prototype indexOf, lastIndexOf and fill (#3798)


We are seeing a memory leak in `Object.values()` and `Object.entries()` when they encounter a getter property that throws an error during value retrieval. The leak is in the enumeration logic (`ecma_op_object_get_enumerable_property_names`); after confirming a property is enumerable, a property descriptor is allocated but only freed later, after the value has been read. If reading the value throws, the descriptor is never released.

**Acceptance Criteria**
1. Calling `Object.values(obj)` or `Object.entries(obj)` where a getter throws must not leak memory: the engine must release any internal property descriptor memory acquired during that enumeration step before propagating the exception.
2. The fix must not affect the memory behavior of `Object.keys()` enumeration, which does not read property values.
3. For any own enumerable property, the descriptor should be freed immediately after the enumerability check and before any operation that might throw (e.g., calling `[[Get]]`). No new leaks should be introduced for the non‑throwing paths.

Fix memory leak in ecma_op_object_get_enumerable_property_names (#4136)


When multiple native pointers are set on an object (using `jerry_set_object_native_pointer` with distinct info pointers), subsequent `jerry_get_object_native_pointer` or `jerry_delete_object_native_pointer` can crash or return incorrect data. The internal `ecma_create_native_pointer_property` function, which extends the native pointer chain, allocates a new `ecma_native_pointer_chain_t` but does not initialize its `next_p` field. This leaves the chain tail with an indeterminate next pointer, corrupting traversal. Ensure that every newly appended chain node has `next_p` explicitly set to `NULL` so that the chain remains well-formed regardless of how many native pointers are added or in what order they are later removed.

Fix uninitialized data in create native property (#4650)


**Bug Report: Bitwise AND, OR, XOR Operators Not Implemented**

**Observed Problem**
JavaScript expressions that use the bitwise logical operators `&` (AND), `|` (OR), or `^` (XOR) always fail. The engine either crashes or reports that the operation is unimplemented. For example, `var x = 5 & 2;` triggers an "unimplemented opcode" error.

Checking the source tree, the opcodes `b_and`, `b_or`, and `b_xor` are still listed in the `OP_UNIMPLEMENTED_LIST` macro, confirming that these three operators are entirely missing from the interpreter.

**Expected Behavior**
According to ECMA-262 5th Edition, Section 11.10, the engine must support the Binary Bitwise Operators `&`, `|`, and `^`.
For any two operands `a` and `b`:
1. Both operands should be converted to `Number` via `ToNumber()`.
2. The resulting numbers should be converted to 32‑bit unsigned integers (following `ToUint32`).
3. The bitwise operation (AND, OR, XOR) should be performed on those 32‑bit integers.
4. The result should be converted back to an ECMAScript `Number` value.

Thus, the operators must work correctly for:
- Integer operands (e.g., `5 & 2` should yield `0`).
- Non‑numeric operands that can be coerced to numbers (e.g., `"5" ^ false`).
- Negative numbers, where the 32‑bit wrapping semantics apply.

Error cases (e.g., when `ToNumber` throws a `TypeError` on an object without `valueOf`/`toString`) should still propagate as exceptions, consistent with the rest of the arithmetic/bitwise family.

**Impact**
Basic scripts that employ these operators cannot run at all. This makes the engine incomplete with respect to the ES5 specification and prevents evaluation of many real‑world JavaScript patterns (flag manipulation, low‑level integer math, polyfills, etc.).

**Request**
Implement the missing opcode handlers for `b_and`, `b_or`, and `b_xor` so that the binary bitwise operators behave as required by the standard.

Implementing b_and, b_or, b_xor opcode handlers.


We are observing crashes (segfaults) when printing very long JavaScript strings that contain specific Unicode sequences, such as unpaired surrogates or CESU-8 encoded surrogate pairs. The issue appears only when the string length exceeds a certain threshold (typically > 65535 bytes in CESU‑8 representation). For example:

```
var src = "var a = 0; while(a) { switch(a) {" ;
for (var i = 0; i < 4000; i++)
    src += "-Infinity" + i + "\u00a0\u00a01.2e3";
src += "\udc00%f0%90%80%80\udc00";
print(src);
```

Running this code with JerryScript causes a segmentation fault. The same happens with similar long strings containing `\udc00%f0%90%80%80\udc00` or `\𝔺\
`. The expected behaviour is that `print()` succeeds without crashing, and that `String.prototype.length` returns the correct number of characters for such large strings.

The root cause seems to be that `ecma_string_get_utf8_length` uses an incorrect pointer for long UTF‑8 (CESU‑8) strings when it has to scan the string to compute the UTF‑8 length. Instead of skipping the full `ecma_long_string_t` header, it uses the offset of the smaller `ecma_string_t` header, leading to reading garbage data and eventually a buffer overflow or miscounted length. This affects any API that converts a CESU‑8 string to UTF‑8 (e.g., `print`, `String.prototype.length`, serializations). The calculation must use the correct start of the string data for long strings to avoid out‑of‑bounds memory access and ensure consistent length results. The fix needs to ensure that `ecma_string_get_utf8_length` correctly offsets past the `ecma_long_string_t` header when dealing with `ECMA_STRING_CONTAINER_HEAP_LONG_UTF8_STRING` containers.

Fix UTF8 string length calculation (#2508)


# Feature Request: Implement `Number.prototype.toFixed()`

The built-in method `Number.prototype.toFixed` is currently unimplemented (returns an "unimplemented" completion).
We need a full implementation according to ECMA-262 5.1 §15.7.4.5.

## Behavioural requirements

1. **Argument handling**
   - `fractionDigits` is an optional argument; when omitted or `undefined`, treat it as `0`.
   - The value must be in the integer range `0 .. 20` inclusive. Otherwise throw a **RangeError**.

2. **Return value**
   Return a **string** representation of `this` Number in fixed‑point notation, containing:
   - an optional `'-'` for negative numbers (including `-0`);
   - the integer part;
   - if `fractionDigits > 0` or the number is zero with positive `fractionDigits`, a decimal point `'.'` followed by exactly `fractionDigits` fractional digits.

3. **Special values**
   - `NaN` → `"NaN"`
   - `Infinity` → `"Infinity"`
   - `-Infinity` → `"-Infinity"`
   - `-0` with `fractionDigits = 0` → `"-0"`
     `-0` with `fractionDigits > 0` → `"-0.` followed by `fractionDigits` zeros (e.g. `(-0).toFixed(1)` → `"-0.0"`).

4. **Rounding**
   The number must be rounded to the required precision. If the exact mathematical value is exactly halfway between two possible representations, round **away from zero** (i.e. “round half up”, pick the larger absolute value).
   *Example:* `0.5` with `fractionDigits = 0` → `"1"`.

5. **Large magnitude numbers**
   If the absolute value of the number is **≥ 10²¹** (i.e. the decimal exponent of the canonical representation is > 21), `toFixed` must fall back to `Number.prototype.toString()` (which will produce exponential notation such as `"1.23e+21"`).
   *Example:* `1.23e21` → `"1.23e+21"`.

6. **Padding**
   When the number has fewer fractional digits than requested, pad with trailing zeros.
   When the integer part is zero, the output must start with `'0'` (or `'-0'` if negative), even for numbers less than 1 (e.g. `0.00023` with `fractionDigits = 2` → `"0.00"`).

## Implementation guidance

- The existing internal helpers `ecma_number_to_zt_string_calc_number_params` (for FLOAT64) and the equivalent inline code for FLOAT32 already extract the “s, n, k” parameters from the standard to‑string conversion. These should be unified and exposed (e.g. as `ecma_number_to_decimal`) so that `toFixed` can reuse them.
- Provide a small rounding helper that trims unnecessary digits and rounds the remaining integer according to the last removed digit.
- Follow the coding patterns of other Number.prototype methods: convert `this` and the argument using `ECMA_OP_TO_NUMBER_TRY_CATCH`, handle the completion value properly, and build the result string using stack‑allocated buffers.


The `is_constructor` check treats bound functions as constructors unconditionally, even when the target function is a built-in that cannot be constructed. This causes runtime errors when a bound built-in is passed as the `this` value to a method that inspects constructability, such as `Array.of`.

### Acceptance Criteria
- Given a bound function created from a non-constructor built-in (e.g., `var boundedBuiltinFn = Array.of.bind(Array)`), querying whether it is a constructor must return `false`.
- `Array.of.call(boundedBuiltinFn, boundedBuiltinFn)` must not throw a `TypeError` and must return an array containing the bound function, because `Array.of` correctly falls back to the standard `Array` constructor when `this` is not a constructor.
- The same logic must apply to any bound function wrapping a non-constructor target, not just `Array.of`. Bound functions whose target is a normal constructor (user-defined or built-in constructors) must still be recognized as constructors.
- The fix must not alter the existing behavior for non-bound functions or for bound functions wrapping constructors.

Fix is_constructor of bound function (#3684)


The parser crashed or exhibited undefined behavior when parsing malformed `import` / `export` statements where a binding name (with or without an `as` alias) was immediately followed by an invalid token, e.g. `import { foo "` or `export { foo as bar "`. Instead of raising a `SyntaxError`, the parser would either crash, corrupt memory, or leak resources.

The parser must handle such inputs gracefully: it **shall** report a `SyntaxError` for any malformed import/export clause without crashing, leaking memory, or invalid memory access. This includes at least these four classes of malformed input:

- `import { <identifier> <garbage>` (single binding, broken token right after the identifier)
- `import { <identifier> as <identifier> <garbage>` (aliased import with broken token)
- `export { <identifier> <garbage>` (single export binding, broken token)
- `export { <identifier> as <identifier> <garbage>` (aliased export with broken token)

The fix must not change the observable behavior for valid module syntax. The implementation must avoid constructing ECMAScript strings until the entire binding (including an optional `as` alias) has been successfully parsed, and must use stable references to parser-internal literal data that remain valid even when the literal pool grows during the parsing of the alias.

Fix allocation problems when using import and export (#2919)


## Bug Report: Missing TypeError When `[[DefineOwnProperty]]` Returns False During Strict-Mode Property Assignment

**Title**: Strict-mode property assignment to a receiver does not throw TypeError when `[[DefineOwnProperty]]` fails

**Severity**: High — silently ignores specification-mandated error, leading to incorrect runtime behavior in strict mode.

**Affected component**: ECMA object operations, specifically `ecma_op_object_put_apply_receiver` in `jerry-core/ecma/operations/ecma-objects.c`.

**Observed behavior**
In strict mode, if a property assignment triggers a `[[DefineOwnProperty]]` operation on the receiver and that operation returns `false` (indicating failure to define the property), JerryScript does **not** throw a `TypeError`. Instead, the assignment silently succeeds without effect, and execution continues as if no error occurred.

**Expected behavior**
Per the ECMAScript specification (sections 9.1.9.1 and 9.5.9), when the `[[Set]]` internal method falls through to `[[DefineOwnProperty]]` on the receiver and that call returns `false`, and the `Throw` parameter is `true` (which is always the case in strict mode code and some built-in operations), a `TypeError` exception must be thrown. The engine should immediately raise an error to inform the caller that the property could not be defined.

**Steps to reproduce**

1. **Non-extensible receiver**
   ```js
   "use strict";
   var obj = Object.preventExtensions({});
   var proto = { x: 1 };
   Object.setPrototypeOf(obj, proto);
   obj.x = 2;   // Should throw TypeError, but does not.
   ```

2. **Proxy receiver with a falsy `defineProperty` trap**
   ```js
   "use strict";
   var handler = {
       defineProperty(target, prop, desc) {
           return false;   // or undefined, 0, etc.
       }
   };
   var proxy = new Proxy({}, handler);
   var obj = Object.create(proxy, {});
   obj.someProp = "value";   // Should throw TypeError, but does not.
   ```

3. **Proxy receiver used indirectly via built-in methods**
   Programs that rely on built-ins (e.g., `RegExp.prototype[Symbol.split]`) which internally perform strict property definitions on receiver objects will also fail to report errors when a proxy’s `defineProperty` trap returns a falsy value.

**Root cause analysis**
In `ecma_op_object_put_apply_receiver`, the results of both `ecma_op_object_define_own_property` (for non-proxy receivers) and `ecma_proxy_object_define_own_property` (for proxy receivers) were not checked for `false` when `is_throw` was `true`. As a result, a failed `[[DefineOwnProperty]]` was silently ignored instead of throwing a `TypeError`.

**Impact**
- Strict-mode code that attempts to set a property on a non-extensible object (with an inherited setter or read-only property) does not receive the mandated error, potentially masking bugs.
- Code operating on Proxy objects expects the proxy’s `defineProperty` trap to enforce invariants; returning a false value means “not allowed,” but the engine ignores that signal.
- This violates the ECMAScript specification and can lead to unexpected behavior in libraries that depend on correct strict-mode error reporting.

**Suggested fix**
After every call to `ecma_op_object_define_own_property` and `ecma_proxy_object_define_own_property` in `ecma_op_object_put_apply_receiver`, check whether the result is `false` and `is_throw` is `true`. If so, return a `TypeError` with an appropriate message (e.g., `"Proxy trap returned falsish"`).

Add strict flag check for ecma_op_object_put_apply_receiver (#4450)


**Title:** `String.raw` mishandles escape sequences for backslash, backtick, and line terminators

**Component:** `jerry-core` (parser/lexer, ES2015 tagged templates)
**Severity:** medium (incorrect output, potential crash)
**Labels:** bug, ES2015, template literals

---

**Description**

When using `String.raw` (or the raw array of a tagged template), the raw strings are supposed to represent the *literal* characters of the template, with the following ES2015 semantics (per 11.8.6.1):

- The escape sequences `\\` and `\`` must appear in the raw string as two characters: the backslash followed by the following character (either a second backslash or a backtick).
  For example, `` String.raw`\\` `` must produce a string containing two backslashes, and `` String.raw`\`` `` must produce a backslash followed by a backtick.
- A backslash followed by a line terminator (including `\u2028`, `\u2029`, and regular line breaks) is a **line continuation**; in the raw string it must appear as the literal backslash followed by the literal line terminator, preserving both characters.
- For line terminators that are three-byte UTF‑8 sequences (U+2028, U+2029), the raw string’s length and literal extraction must account for all three bytes correctly.

**Current behaviour**

- `String.raw` does not properly output the pairs for `\\` and `\`` – it either processes them as normal escape sequences (losing one character) or, in some cases, triggers a parser crash (e.g. when a raw template ends with a backslash).
- Line continuation handling in raw mode is missing or broken: the backslash and the following line terminator are not correctly included in the raw output, and the source–length accounting for three‑byte line terminators is wrong, leading to corrupted raw strings or crashes.

**Expected behaviour**

1. **Backslash/backtick in raw strings**
   Inside a raw template literal, any occurrence of `\` followed by `\` or `` ` `` must be emitted unchanged into the raw string (i.e. as the two literal characters that appear in source).

2. **Line continuations in raw strings**
   A backslash immediately followed by a line terminator (physical newline, `\u2028`, or `\u2029`) must result in the raw string containing exactly those two characters: the backslash and the line terminator.
   The lexer’s internal length calculation must correctly account for multi‑byte line terminators when `LEXER_STRING_RAW` is set.

3. **Empty raw strings with escape sequences**
   In the tagged-template-literal assembly step, an empty string literal that *does* contain escape sequences (e.g. a single backslash at the end of a template) must not be silently dropped; it still represents a meaningful segment and must be appended as an empty cooked string / raw string as appropriate.

**Affected code areas**
- `jerry-core/parser/js/js-lexer.c` (functions `lexer_parse_string` and `lexer_convert_literal_to_chars`)
- `jerry-core/parser/js/js-parser-tagged-template-literal.c` (function `parser_tagged_template_literal_append_strings`)

The fix should ensure that when the lexer encounters a raw string, the escape‑pair and line‑continuation cases described above are handled without interpreting the escape, and that the literal‑to‑chars conversion duplicates the raw characters correctly. Additionally, the tagged‑template assembly must not skip empty raw strings when the `has_escape` flag is set.

Add support of escaping backslash and backtick to String.raw (#3736)


**Title:** `RegExp.prototype.exec` crashes with "property_p != NULL" assertion when `this` is not a fully-initialized RegExp instance

**Description**

Calling `RegExp.prototype.exec` with the native RegExp prototype (or any object that lacks a compiled bytecode) as the `this` value triggers a fatal assertion failure: `property_p != NULL`. This prevents generic use of the `exec` method as required by the ECMAScript specification.

**Steps to reproduce**

1. Execute `RegExp.prototype.exec("10")` or `RegExp.prototype.exec(10)` in the JerryScript engine.

**Expected behavior**

The call should return an array:

    [""]

with additional `index` set to `0` and `input` set to `"10"`.

Per ECMA-262 5th edition §15.10.6.2, when `exec` is applied to an object that is not a RegExp instance, it should behave as if the pattern was the empty regular expression `(?:)`. For an empty pattern, `exec` must always succeed and return an empty-string match at the beginning of the input string.

**Actual behavior**

The engine crashes with an assertion failure:
`property_p != NULL`
in `ecma_get_internal_property` or `ecma_free_internal_property`.

The crash occurs because the RegExp prototype object does not contain a bytecode internal property (or it contains an uninitialized/null pointer), and the `exec` path unconditionally tries to retrieve and use the bytecode without checking for its presence before proceeding to compile or match.

**Impact**

- Cannot use `RegExp.prototype.exec` generically, for example to emulate a no-op match, which breaks ECMAScript conformance.
- Any code path that may call `exec` on an unusual `this` value risks a hard crash.
- The internal property cleanup code also does not handle a NULL bytecode pointer when freeing the `REGEXP_BYTECODE` internal property, which can lead to crashes during garbage collection or object teardown.

**Request**

Please make the following behaviour changes:

1. Ensure that `RegExp.prototype.exec` gracefully handles the case where the object’s `REGEXP_BYTECODE` internal property is missing or contains a NULL pointer. When no bytecode is available, `exec` should proceed as if the pattern is empty – create a result array set up for a zero-length match at index 0 with the full input string.

2. Ensure that the RegExp prototype object is initialised with a NULL bytecode pointer (or an equivalent sentinel) during built-in setup, so that calls to prototype methods on it do not attempt to dereference a non-existent property.

3. Ensure that the internal property free routine (`ecma_free_internal_property`) expressly checks for a NULL bytecode pointer before calling `mem_heap_free_block`, instead of invoking `ECMA_GET_NON_NULL_POINTER` which asserts non-NULL.

**Additional context**

The root problem is that the regexp subsystem assumes every object with a RegExp bytecode property has a valid compiled bytecode, but the built-in prototype (and potentially arbitrary user objects) may not have one. The fix should protect all entry points that read the bytecode property against NULL values, and initialise the prototype consistently.

Fix 'property_p != NULL' assertion fail in RegExp


# Bug Report: Duplicate index entries cause incorrect stream event reads and last event number

## Summary
When the index contains duplicate entries for the same stream and event number (for example, due to hash collisions or actual duplicate writes), reading stream events forward/backward returns duplicate events, and the reported last event number is wrong. Additionally, building the index from a transaction file that contains duplicate events can permanently cache an incorrect last event number, leading to persistent inconsistencies.

## Description
EventStore’s index may contain multiple entries for the same stream and event number, each pointing to a different log position. The system should treat only the most recent (highest log position) entry as authoritative for a given version. Currently, the index reader does not consistently collapse duplicates, and the last-event-number calculation can be misled by encountering a duplicate entry with a lower version or by hash collisions that match the hash but not the stream.

### Affected operations
- `IndexReader.ReadStreamEventsForward` / `ReadStreamEventsBackward`
- `IndexReader.GetStreamLastEventNumber` (both cached and uncached paths)
- `IndexCommitter.Init` (index rebuild from the transaction file)

## Steps to Reproduce
1. Write several events to a stream so that the index contains entries for versions 0, 1, 2.
2. Write a duplicate event for version 0 (same stream, different event id and log position). This creates two index entries for version 0.
3. Ask for the stream’s last event number via the client API or internal reader.
4. Read events forward or backward from the stream.

## Expected Behavior
- Reading events forward/backward returns exactly one event per event number; the log position returned should be the highest log position available for that version (i.e., the most recent write).
- `GetStreamLastEventNumber` returns the maximum event number present in the stream (2 in the example), not a lower number from a duplicate.
- Building the index from an existing transaction file that contains duplicate events should not cache a wrong last event number; a subsequent read should still report the correct maximum version.

## Actual Behavior
- Stream reads may include duplicate entries for the same event number.
- `GetStreamLastEventNumber` can return 0 instead of 2 if it encounters the first duplicate entry and incorrectly assumes that is the last.
- During index rebuild, the committer may cache the duplicate’s version as the stream’s last event number, causing all future reads to see the wrong value until the cache is invalidated.

## Additional Constraints & Non-Obvious Edge Cases
- The fix must work when the duplicate entry resides in a **64-bit PTable** while earlier entries are in 32-bit tables (or vice versa), ensuring that merging across table versions does not reintroduce duplicates.
- When calculating the last event number, the hash collision read limit must still be respected, and the algorithm must not cause an infinite loop or premature abortion. It should scan all entries up to the limit, collect the maximum version among those that truly belong to the stream (matching prepare record stream id), and only return `NoStream` if no matching entry is found.
- During **index rebuild** (`IndexCommitter.Init`), the committer must avoid caching the stream’s last event number (and avoid performing additional commit checks that assume a monotonic version sequence) because duplicates may violate those assumptions. The cache should be deferred until normal operation, after the full index is available.
- `IndexCommitter.Commit` is called both during rebuild and during normal chaser operation. The caller in `StorageChaser` should continue to cache the last event number during normal commits; the rebuild path must use a separate code path that suppresses caching.

## Impact
This bug can lead to stream metadata clients observing `lastEventNumber == 0` for a stream that actually has many events, causing them to think the stream is empty or not up-to-date. Duplicate events returned by reads violate the EventStore contract of a single ordered event per version, breaking projections and subscribers.

Merge pull request #1099 from EventStore/hash_collision_additional


**Feature Request: Dynamic license expiry reporting in `/license` endpoint and telemetry**

**Background**
Currently the `/license` endpoint exposes `daysRemaining` and `isExpired` from a snapshot taken at license validation time. This means the values can be stale and do not reflect the actual time remaining at the moment the endpoint is queried. Additionally, the telemetry stream publishes the same static `isExpired` flag once and never updates it.

**Acceptance Criteria**

1. **`/license` endpoint response**
   When an authenticated client requests the licensing endpoint, the JSON response must include:
   - `daysRemaining` (string) – The number of days until expiry, calculated as `max( (expiryUtc - nowUtc).TotalDays, 0 )`, formatted with two decimal places (e.g., `"2.04"`, `"0.00"`).
   - `isExpired` (string) – `"true"` if the expiry timestamp is in the past (i.e., `expiryUtc < nowUtc`), otherwise `"false"`.
   - Both values must be computed **at request time**, not stored from a previous validation event.
   - For backward compatibility with existing WebUI, the response must still contain:
     - `"isFloating": "true"`
     - `"startDate": "0"`

2. **Expiry timestamp source**
   The expiry should be represented as a Unix timestamp (seconds since epoch) derived from the license’s expiry date.
   - If a license has no expiry (e.g., perpetual or inconclusive), treat the expiry as `DateTimeOffset.MaxValue`, resulting in a very large `daysRemaining` and `isExpired = false`.

3. **Inconclusive license (validation failure)**
   When license validation conclusively fails, the system issues a temporary “Temporary License” (instead of “Fallback”). This temporary license must:
   - Be marked as invalid (`"isValid": "false"`).
   - Not be trial, not expired, and floating.
   - Have `daysRemaining` calculated as if it never expires (i.e., huge value).
   - Contain the note `"License could not be validated. Please contact EventStore support."`.

4. **Telemetry updates**
   The telemetry reporting service must periodically recalculate and publish the license `isExpired` flag (based on the current UTC time versus the expiry).
   - The telemetry payload should reflect the actual expiry status at the time of publishing, not a one-time snapshot.
   - The service should emit an update at least once per hour while the license is known.

5. **No breaking changes to other fields**
   - `licenseId`, `company`, `isTrial`, `isValid`, and `notes` must remain present and unchanged in behavior.
   - The `LicenseSummary` record must no longer expose pre-computed `IsExpired`, `IsFloating`, `DaysRemaining`, or `StartDate` as stored properties; expiry must be stored as a raw Unix timestamp for runtime calculation.

**Edge cases / safety constraints**
- Ensure `daysRemaining` cannot be negative; clamp to `0.00` when expired.
- When the expiry timestamp string is missing or unparseable, the system must default to treating the license as not expired (max days remaining).
- The change must not alter the authentication requirements or HTTP status codes returned by the endpoint.
- Telemetry updates must not interfere with the existing lifecycle of license validation and must stop when the license is no longer available.

[master] Calculate days remaining when querying /license endpoint (#4591)


**Title:** Add an `$all` system group to grant public access in stream ACLs

**Problem**
A stream’s access control list (ACL) can restrict operations to a specific user group by setting the `$r`, `$w`, `$mr`, or `$mw` metadata fields to a role name like `$admins`. If a role is `null`, the behavior differs between regular and system streams: regular streams grant access to anyone, while system streams deny access to unauthenticated users and non‑admins. There is no way to explicitly declare that a stream should be publicly readable/writable (accessible to all users, authenticated or not) using the ACL metadata. This makes it impossible to opt into uniform public access on system streams or to make the access intent clear on regular streams.

**Desired Behavior**
Introduce a reserved role name, `$all`, that can be used in any ACL field (`$r`, `$w`, `$mr`, `$mw`). When one of those fields is set to `$all`, the corresponding operation should succeed for **any** principal, including unauthenticated users. The `$all` role should override any other built‑in restrictions for that permission and apply consistently to both regular and system streams.

Examples:
- `StreamMetadata.Build().SetReadRole("$all")` → any user can read the stream (forward/backward, metadata, and subscribe) without credentials.
- `StreamMetadata.Build().SetWriteRole("$all")` → any user can write to the stream or start transactions without credentials.
- On system streams (e.g., `$myStream`) setting a role to `$all` must allow the corresponding operation even when an unauthenticated (`null`) principal is used, where the default `null` role would deny it.

**Impact**
Without this feature, operators cannot grant broad, explicit public access to event streams. They must either leave roles `null` (with inconsistent system‑stream behavior) or enumerate every possible group, which is not scalable. Adding `$all` provides a clear, self‑documenting way to open a stream to all users, improving security configurability and consistency.

Added: security access for all users ($all), added more tests for security.


The authentication and authorization providers should be able to register middleware and services in the ASP.NET Core pipeline, just like other pluggable components (e.g., subsystems). Currently, only subsystems participate in the startup configuration; auth providers are excluded.

Acceptance criteria:
- The interfaces `IAuthenticationProvider` and `IAuthorizationProvider` must expose `Configure(IApplicationBuilder)` and `ConfigureServices(IServiceCollection, IConfiguration)` methods, following the same pattern as `IPlugableComponent`.
- During node startup, the cluster node should gather all pluggable components and invoke their `ConfigureServices` and `Configure` methods. This list must include the authentication and authorization providers obtained from the configured factories.
- A custom authentication provider or authorization provider registered via the appropriate factory should observe its `Configure` and `ConfigureServices` methods being called before the server begins accepting requests, and in an order consistent with other pluggable components (middleware, endpoints, etc.).
- Existing internal and delegated authentication/authorization providers (e.g., `DelegatedAuthenticationProvider`) should continue to work and correctly delegate calls to their inner providers. No externally visible behavior of the default providers should change.
- The startup code that previously handled only `ISubsystem` instances should now operate over `IPlugableComponent`, without changing the logical ordering of configuration steps.

Wire up Authorization/Authentication/MD5 plugins to DI


**Title:** Write a `$scavengeIndexInitialized` event to the `$scavenges` stream on startup

**Background:**
The `$scavenges` stream records scavenge lifecycle events. Currently, only `$scavengeStarted` and `$scavengeCompleted` events are written when a scavenge is triggered. There is no event that marks the point when the scavenge subsystem itself becomes ready (e.g., after the user management service is initialized). This makes it harder for external tooling and monitoring to know when the database is fully ready for scavenging and to correlate the scavenge history across restarts.

**Request:**
Introduce a new system event type `$scavengeIndexInitialized`. On node startup, after all core services (specifically the user management service) have initialized, the storage scavenger must write a single `$scavengeIndexInitialized` event to the `$scavenges` stream.

**Behavioral requirements:**
- The event type string must be `"$scavengeIndexInitialized"`.
- The event should be written with an empty payload (no metadata necessary) and `ExpectedVersion.NoStream` so that it creates the stream if it does not exist.
- It must be published exactly once per node lifetime – when the node transitions to fully ready (the `UserManagementServiceInitialized` message is a suitable trigger).
- The event must appear in the `$scavenges` stream *before* any `$scavengeStarted` or `$scavengeCompleted` events that might later be appended for user-initiated scavenges.
- The existing scavenge lifecycle events (`$scavengeStarted`, `$scavengeCompleted`, `$scavengeChunksCompleted`) and their linkage behavior remain unchanged.

**Acceptance criteria:**
- On a fresh node, reading the `$scavenges` stream from the beginning immediately after startup yields a single `$scavengeIndexInitialized` event.
- Subsequent scavenge runs append `$scavengeStarted` and `$scavengeCompleted` to the same stream, so a full read of the stream will have the initialization event followed by any run events.
- The implementation should not alter how scavenge triggers are requested or executed.

Write a ScavengeIndexInitializedEvent to the scavenges stream on startup.


**Bug: Projection recovery can hang due to untracked read timeouts**

During projection checkpoint recovery, the emitted streams component submits a backwards read to the `IODispatcher` to list events that have already been committed to the stream. If that read does not complete within the expected time, a timeout is triggered. Currently, the timeout is implemented by manually publishing a `TimerMessage.Schedule` and handling a custom `ReadTimeout` message inside `EmittedStream`.

This approach bypasses the `IODispatcher`’s own request tracking. The dispatcher has no knowledge that the read has timed out, so the pending correlation ID is not properly released. As a result, the `IODispatcher` may still consider the read in-flight, which can:

- cause subsequent reads to be delayed or never issued,
- leave the projection recovery stuck waiting for a read that will never complete,
- produce unexpected behavior if the original read eventually completes after the manual timeout has already triggered a retry.

**Expected behavior:** Read timeouts during recovery should use the timeout mechanism provided by `IODispatcher.ReadBackward`. The dispatcher must be responsible for enforcing the timeout, canceling the pending request, and invoking a specified timeout action so that the stream can retry the read safely. The `EmittedStream` should not implement its own timer-based timeout for these reads.

**Impact:** Projections may fail to recover from checkpoints under conditions where reads are slow or the connection is under load, leading to permanently stalled projections and requiring manual intervention to restart the node.

**Constraints for a fix:**
- The `EmittedStream` must no longer implement `IHandle<ProjectionManagementMessage.Internal.ReadTimeout>`.
- When submitting the backwards read to the `IODispatcher`, a timeout action must be supplied that performs the same retry logic previously handled in the removed message handler, specifically re-submitting the read from the same `fromEventNumber` and `upTo` checkpoint tag.
- The correlation ID of the original read must be cleared and the “awaiting list events” flag must be reset only if the read is still the current pending request (stale timeouts must be ignored).
- The change must not affect the non-recovery paths or the write timeout handling.

Use the IODispatcher timeout for catching up


Currently, `ClientCertificateAuthenticationProvider` (in `src/EventStore.Core/Services/Transport/Http/Authentication/`) treats any non-null client certificate as sufficient to authenticate the caller as the system user. This is too permissive.

We need to tighten the check: the provider must require that the client certificate includes a Subject Alternative Name (SAN) extension (OID `2.5.29.17`) with at least one entry of type `dNSName` or `iPAddress` (i.e., a DNS name or an IP address).

- If the certificate is null, authentication must fail.
- If the SAN extension is missing, or if the extension data cannot be parsed (e.g., a `CryptographicException` while accessing the extensions), authentication must fail.
- If the SAN extension is present but contains only entries of other types (e.g. email, URI, UPN), authentication must fail.
- Only certificates that satisfy the IP/DNS SAN requirement should be authenticated and assigned the system identity.

No other roles or claims should be assigned in any case.

Require an IP or DNS SAN to be present in a client certificate to be authenticated as system user


We need to simplify the statistics report that projection cores write to the `$projections-$master` stream. Currently the `CoreProjectionStatusMessage.StatisticsReport` carries a full `ProjectionStatistics` object, which in turn includes the entire `ProjectionSourceDefinition` via its `Definition` property. This is both heavy and unnecessary – the only consumer that needs anything from that definition is the HTTP formatter, and it only uses the result stream name to build the `ResultStreamUrl`.

**Desired changes:**
- Replace `ProjectionStatistics.Definition` (of type `ProjectionSourceDefinition`) with a simple `string ResultStreamName`.
- Update `DefaultProjectionProcessingStrategy.EnrichStatistics` to populate `ResultStreamName` from `_sourceDefinition.ResultStreamNameOption` instead of assigning the whole definition.
- In `ProjectionStatisticsHttpFormatted`, build the `ResultStreamUrl` directly from `source.ResultStreamName` instead of reaching into `source.Definition`.
- At the same time, fix the serialization typo: the `StatisticsReport` envelope written by `ProjectionCoreResponseWriter` uses a property named `Statistcs` (and therefore a JSON field `"Statistcs"`). Both the writer and the reader (`ProjectionManagerResponseReader`) must be aligned on the correct spelling `"Statistics"` so that deserialization succeeds and field names are consistent with the rest of the system.

The observable behaviour after these changes:
- `$statistics-report` events on `$projections-$master` no longer emit the full source definition; they only contain the result stream name.
- The HTTP API response for a projection’s statistics still includes a valid `resultStreamUrl` when a result stream name is set.
- The statistics report is correctly read back by the manager, and all existing callers continue to receive projection statistics without schema mismatch.

Fixed: statistics report response reading


Update the HTTP client certificate authentication provider to require that accepted certificates have a Subject of exactly `CN=eventstoredb-node` in addition to containing an IP or DNS Subject Alternative Name entry. Authentication must succeed only when **both** conditions are met: the Subject string case-sensitively equals `CN=eventstoredb-node` and the SAN extension includes at least one IP address or DNS name. Reject certificates that satisfy only one of these conditions (for example, matching Subject but no IP/DNS SAN, or an IP/DNS SAN but a different Subject). Also continue to reject certificates whose extensions or Subject cannot be read due to cryptographic errors.

Also ensure that we have a specific common name (CN=eventstoredb-node) in the certificate's Subject field.


**Title:** TransactionFileReaderEventDistributionPoint – notify subscribers when caught up and idle

**Background**
Projections subscribed via `HeadingEventDistributionPoint` currently only receive `CommittedEventDistributed` messages when the transaction file reader advances. When the reader reaches the end of the transaction file (EOF) and there are no further events to process, it simply waits. This means projections cannot distinguish between “still catching up” and “fully caught up, waiting for new writes”. For projections that need to act on idle periods (e.g. flush state, emit timeouts, update progress), we need an explicit idle signal.

`ProjectionCoreServiceMessage.EventDistributionPointIdle` already exists in the messaging protocol and is handled by the heading distribution point and projection subscriptions, but the transaction-file based reader never sends it.

**Request**
Have `TransactionFileReaderEventDistributionPoint` publish an `EventDistributionPointIdle` message (with a UTC timestamp) whenever it reaches EOF and all buffered events up to that point have been delivered.

**Detailed behaviour**
- After handling a `ClientMessage.ReadAllEventsForwardCompleted` that returns zero events (i.e. EOF) and delivering the last commit position if `deliverEndOfTFPosition` is enabled, the reader must publish a single idle notification.
- The idle timestamp must be obtained from a `ITimeProvider` passed into the constructor, **not** directly from `DateTime.UtcNow`, so that time can be controlled in tests.
- The idle message is sent before re-requesting events or entering the wait state.
- Every subsequent EOF during catch-up or live tail should produce a new idle message (one per read cycle).

**Snapshot behaviour**
- When re-requesting events after an idle notification (e.g. after a short delay), no additional idle notification is sent for the same cycle unless the follow-up read also returns empty.
- The idle notification must flow through the existing distribution path: `TransactionFileReaderEventDistributionPoint` → `HeadingEventDistributionPoint` → subscribed `IProjectionSubscription` instances.

**Acceptance criteria**
- All existing callers that construct a `TransactionFileReaderEventDistributionPoint` must supply a time provider (typically `RealTimeProvider` for production usage).
- Unit tests and production code demonstrate that after reading a batch that ends at EOF, the idle message is emitted and its timestamp reflects the current time provider value.

Added: TransactionFileReaderEventDistributionPoint - idle message support


# Bug: `UnbufferedFileStream` integer overflow when writing large PTable files

## Observed behavior

When a PTable grows beyond approximately `Int32.MaxValue` index entries (roughly 34 billion records or ~512 GB in file size), writes through `UnbufferedFileStream` fail with incorrect data or unexpected exceptions. The internal buffered-write counter and several offset/count tracking variables are declared as `int`, so they overflow silently once the accumulated byte count exceeds 2,147,483,647.

Additionally, it is not possible to manually create or validate a PTable file larger than this threshold because the existing test helper does not construct a well-formed PTable file (no valid MD5 hash, no properly serialized index entries), making it impossible to exercise the read path for such large tables.

## Expected behavior

- `UnbufferedFileStream` must support files whose write operations span more than `Int32.MaxValue` bytes in aggregate. All internal counters and offset arithmetic that track cumulative buffered data should use 64‑bit (`long`) types so no overflow occurs.
- It must be possible to create a large PTable file on disk that contains a valid version‑1 header, a contiguous run of properly sized index entries, and a correct MD5 hash over the header and entry content, then open that file via `PTable.FromFile` and observe the correct entry count.

## Impact

This is a correctness and data‑integrity issue. Without the fix, PTable merging or flushing operations that produce files larger than ~512 GB will corrupt the output, potentially causing silent data loss or crashes during index reads. The ability to test and validate the 64‑bit‑clean path is blocked until the test tooling can generate well‑formed files of the required size.


## Bug Report: Deleted projections can resurrect after EventStore restart due to incorrect batch reading of the registration stream

**Severity:** High
**Affected Component:** Projection Management (EventStore.Projections.Core)
**Observed Behavior:**
After EventStore restarts, a projection that was previously deleted (without removing its state streams) reappears in a **stopped** state instead of staying deleted.

**Steps to Reproduce:**
1. Create at least 200 projections (more than double the current batch size for reading the registration stream).
2. Delete the first projection, explicitly choosing **not** to delete any of its state/checkpoint/emitted streams.
3. Restart the EventStore node.
4. Query the projection list or statistics.

**Expected Behavior:**
The deleted projection should not appear in the projection list. It should remain deleted and not be started or reported.

**Actual Behavior:**
The deleted projection is listed with a stopped status, effectively being “resurrected” after the restart.

**Impact:**
- Deleted projections may be unintentionally re-exposed, leading to stale or incorrect processing states.
- Users may see stopped projections they assumed were permanently removed, causing confusion and potential misuse.

**Root Cause Hypothesis:**
During startup, the `$projections-$all` registration stream is read **backwards** in batches. A grouping function attempts to deduce the final liveness (Created vs. Deleted) of each projection by looking at the most recent event for that projection name within the batch. Because the stream is read backwards and events can be split across batches, a deleted projection whose `$ProjectionDeleted` event falls outside the current batch can be incorrectly classified as “alive” based on an earlier-seen `$ProjectionCreated`. This leads to the projection being initialized and started (even if stopped) after restart.

**Required Fix:**
- Change the reading of the registration stream from **backward** to **forward** (from the beginning).
- Process events sequentially in natural chronological order to build a live set of projections:
  - Create events add a projection to the set; delete events remove it.
  - An `$ProjectionsInitialized` event marks the start of the stream (no projections alive yet), but the algorithm should handle streams that don’t have this event as well.
- After finishing the read, start only those projections that remain in the live set.
- Eliminate hardcoded strings for the registration stream name (`"$projections-$all"`) and the well-known event types (`"$ProjectionCreated"`, `"$ProjectionDeleted"`, `"$ProjectionsInitialized"`, `"$ProjectionUpdated"`). Use shared constants to reduce future bugs from typos and improve maintainability.

**Non‑Obvious Requirements / Edge Cases:**
- The projection ID (event number) used for ordering must accommodate the special case where the first event has number 0 (treat it as `Int32.MaxValue - 1` to avoid ID collisions).
- Duplicate projection registration entries (unexpected but possible) should be logged and skipped without crashing.
- The change must also handle the `$ProjectionsInitialized` event correctly: when present, it should be recorded but does not represent a projectable projection.
- System projections (the standard `$by_category`, `$stream_by_category`, etc.) must still be created automatically if they don’t exist and `InitializeSystemProjections` is true.
- When no registration stream exists, the system should write a `$ProjectionsInitialized` event and then create system projections as before.
- The fix must preserve existing behavior for partially created projections (where a `$ProjectionCreated` event exists but the configuration stream is missing)—these should still be reported with a “Creating” status.
- After the fix, deleted projections must never reappear after a restart, regardless of batch sizes or the number of projections.

Reading registered projections in batches can cause deleted projections


We need the chunk bulk-reader to distinguish between the raw on-disk bytes and the logical event data that excludes per-chunk metadata. Today `TFChunkBulkReader.ReadNextBytes` returns whatever is on disk, forcing every caller to compute offsets for headers, footers, and scavenge maps. This is error-prone and prevents multiple consumers (replication, scavenging, index building) from using the same simple bulk-read API.

**Acceptance criteria**

1. **Separate logical versus physical bulk reads**
   - The bulk reader shall expose two distinct operations: one for reading *logical* bytes and one for reading *physical* bytes.
   - Logical bytes are the actual event payload the chunk carries, without the chunk header, chunk footer, or scavenge position map.
   - Physical bytes are the raw file content from the current read position to end-of-file, including all structure (header, footer, map).

2. **Logical reads on a completed, non-scavenged chunk**
   - When the chunk is completed (not scavenged), a logical bulk read starting at the beginning of the payload returns exactly the data between the end of the header and the start of the footer.
   - `IsEOF` becomes true immediately after the last logical byte is read. The number of bytes read in the final call equals the remaining logical data, not including the footer.
   - Example: a chunk with 300 bytes of payload — reading 1024 logical bytes returns 300 and marks `IsEOF`.

3. **Logical reads on a scavenged chunk**
   - After a chunk has been scavenged (a position map appended after the data), logical reads must exclude the map bytes as well as the header and footer.
   - The available logical data is the payload that existed before the map was written.
   - `IsEOF` and byte counts are computed such that the map is entirely invisible to the logical reader.

4. **Physical reads**
   - Physical bulk reads simply consume the underlying stream from the current position to the physical end of the file.
   - For a completed chunk this includes header, data, footer. For a scavenged chunk this includes header, data, map, footer.
   - No special offset skipping is performed; the caller receives all bytes on disk.

5. **Read-ahead and buffer limits**
   - When the requested count exceeds the caller’s buffer size, the reader shall limit the actual read to the buffer size. This applies to both logical and physical reads.
   - The reader shall not overrun the buffer, and subsequent calls continue where the previous stopped.

6. **Lifetime and delete-safety**
   - While a bulk reader is held (not disposed), the owning chunk must not be physically deleted from disk even if `MarkForDeletion` is called.
   - Once all readers release, normal destruction can proceed.

7. **Initial stream position**
   - The logical reader shall automatically position the underlying file stream past the chunk header on first use if it has not yet been advanced. The physical reader shall read from whatever position the stream is at (typically zero) without repositioning.

This separation eliminates manual offset arithmetic from consumers and correctly handles both intact and scavenged chunk files.


**Title:** Add a catalog-stream event reader for projections

**Context:**
Projections currently support reading from a single stream (`ByStream`) or from `$all`. There is no built-in reader for the pattern where a “catalog” stream references multiple streams, and the projection must consume events from each referenced stream in order.

A catalog stream is a user-written stream whose events are either `$>` (link-to) events carrying `eventnumber@streamid`, or `$@` (stream-reference) events carrying a plain stream id. The reader must forward through the catalog, collect the referenced stream names, and then sequentially read the events of each referenced stream.

**Ask:**

Implement a new `EventReader` subclass – `ByStreamCatalogEventReader` – in the `Processing` namespace that:

1. **Catalog reading:**
   - Reads the catalog stream forward from a given `catalogNextSequenceNumber`.
   - For each event of type `$>` or `$@`, extracts the target stream id and enqueues it.
   - When the catalog end-of-stream is reached, marks the catalog as exhausted.

2. **Data-stream reading:**
   - Processes the enqueued stream names one after another.
   - Reads events from the *current* data stream starting at a given `dataNextSequenceNumber`, respecting `resolveLinkTos`.
   - If the data stream is `NoStream` or `StreamDeleted`, skips it and moves to the next queued stream.
   - When the end of the current data stream is reached, dequeues the next stream (or proceeds to EOF if both catalog and queue are exhausted).

3. **Checkpoint-tag compatibility:**
   - The current `ByStream` checkpoint tag (stored via `FromByStreamPosition`) holds `catalogStream`, `catalogPosition`, `dataStream`, and `dataPosition`.
   - Update `CheckpointTag` so that a state without an active data stream is representable: `dataStream` may be null/empty and `dataPosition` may be `-1`.
   - Adjust JSON serialisation (`WriteTo`/`FromJson`) to **omit** the data-stream object when no data stream is active, and to accept its absence during deserialisation (fall back to `dataStream = null`, `dataPosition = -1`).
   - This change must remain backward-compatible with existing serialised tags that always contain the data-stream object.

4. **Error handling and lifecycle:**
   - `AccessDenied` on either the catalog or the current data stream must immediately signal not-authorised and stop reading.
   - The reader must respect `stopAfterNEvents`, pausing and disposition as defined in the base `EventReader`.
   - Deliver events with a progress value; a suitable approximation derived from catalog position is acceptable (e.g. constant progress if finer granularity is not needed immediately).
   - Ensure integration with the `IODispatcher` for async reads and with the projector pause/resume contracts.

5. **Registration:**
   - Include the new file in `EventStore.Projections.Core.csproj` so it is compiled.

**Non-goals / constraints:**
- No new end-user query or HTTP API is required; this is internal projection plumbing.
- The existing `FromByStreamPosition` factory must continue to accept `null`/empty data stream and `-1` data position without throwing.
- The serialisation test needs to cover the new “zero” case (no data stream) to guard the format change.

Added: by stream catalog event reader (no tests)


**Title:** Percent‑encoded characters in URL path segments prevent the HTTP router from matching registered routes

**Description**
When an HTTP client sends a request with percent‑encoded characters in the path (e.g. `/data/%20item`, `/data/%24value`, `/data/%D0%B9%D1%86%D1%83%D0%BA%D0%B5%D0%BD`), the router fails to match any route that uses a placeholder for that segment.  The same problem occurs when the encoded character appears literally in the registered URI template and the client sends the encoded form (for example registering `/data/$ref` and receiving `/data/%24ref`).  The result is a 404 response instead of the expected handler invocation with the decoded value.

**Expected behavior**
- A route defined with a placeholder, e.g. `/data/{item}`, should match a URI like `/data/a%20b` and extract the bound variable `item` with the **unescaped** value `"a b"`.
- Reserved characters such as `$`, `%`, and space (` `) that are URL‑encoded in the request (`%24`, `%25`, `%20`) should be decoded before matching and bound to the placeholder.
- Query‑string parameters that are part of the route template (e.g. `?b={b}`) must be extracted from the request’s query string and made available as bound variables, again in unescaped form.
- The routing should work equivalently whether the request path contains `a%20b` or `a b` (when the latter is possible) – the server must decode percent‑encoded octets when deciding which handler handles the request.

**Observed problem**
- The `TrieUriRouter` is given `Uri.Segments` directly.  The .NET `Uri.Segments` property **does not** unescape percent‑encoded characters; it keeps them literally as `%20`, `%24`, etc.  Consequently the trie traversal sees `%20` as a literal three‑character sequence, fails to match a placeholder expecting a decoded space, and no route matches.
- Even after a match is found, bound variables would contain the raw encoded form, breaking downstream logic that expects decoded values (e.g. stream names, resource identifiers).

**Impact**
- Any client that sends URL‑encoded characters (as required by HTTP for unsafe octets, non‑ASCII text, or reserved characters used as data) cannot reach parts of the HTTP API that rely on path‑segment matching.  This includes common cases like spaces in names, identifiers containing `$`, or international characters.
- The issue affects all HTTP endpoints that use path‑segment placeholders or literal reserved characters, including those exposed by the core event store API.

**Suggested resolution approach**
- Unescape each segment from `Uri.Segments` before using it to walk the route trie, so that matching operates on the decoded form.
- Ensure that when a match is found, the bound variables receive the unescaped strings.
- For literal reserved characters in route templates (e.g. a route that expects a literal space or `$`), the unescaping should be applied consistently so that an incoming `%24` matches a literal `$` in the template, and vice‑versa.


**Title:** Complete feed reader paging logic for `FeedReaderMessage.ReadPage` requests

**Background**
The projections core already defines `FeedReaderMessage.ReadPage` (request) and `FeedReaderMessage.FeedPage` (response), along with a `FeedReader` class stub and a `FeedReaderService` handler. The reading side needs to be wired up so that a `ReadPage` request actually subscribes to the event reader, collects a finite batch of events, and returns them in a `FeedPage` when the underlying subscription reaches EOF.

**Expected behavior**

- When `FeedReaderService` receives a `ReadPage` message it creates a new `FeedReader` and starts it.
- The `FeedReader` subscribes via the existing `PublishSubscribeDispatcher<ReaderSubscriptionManagement.Subscribe, …>` using a subscription definition derived from the requested `QuerySourcesDefinition` and `FromPosition`.
- The subscription is configured to stop after `MaxEvents` events **and** to stop on EOF (i.e., `StopAfterNEvents = MaxEvents, StopOnEof = true`).
- Incoming `CommittedEventReceived` messages are buffered internally.
- When `EofReached` is delivered (regardless of whether the limit was hit), the `FeedReader` replies with a single `FeedPage` containing the collected events, and then unsubscribes.
- The events in the `FeedPage` **must** appear in ascending order by their reader position (and by underlying event position).

**Validation and edge cases**

- Constructor must reject:
  - `null` `subscriptionDispatcher`, `querySource`, `fromPosition`, or `replyEnvelope` → `ArgumentNullException`
  - `maxEvents` ≤ 0 → `ArgumentException`
- If no events are collected before EOF, the `FeedPage` should contain an empty `Events` array (and a reasonable `LastReaderPosition`).
- No `FeedPage` is published before EOF is reached, even if the limit of events has been buffered.

**Acceptance criteria**
1. A `ReadPage` with valid parameters results in a `FeedPage` response after EOF, containing up to `MaxEvents` ordered events.
2. Invalid inputs (null arguments, non-positive maxEvents) are rejected at construction time.
3. The feed reader unsubscribes from the event reader after sending its response.

**References**
- `EventStore.Projections.Core.Messages.EventReaders.Feeds.FeedReaderMessage` – request/response types
- `EventStore.Projections.Core.Services.Processing.EventReaderSubscriptionMessage.CommittedEventReceived`, `.EofReached` – subscription events
- `EventStore.Projections.Core.Services.Processing.TaggedResolvedEvent` – event container with reader position
- Existing `FeedReaderService` handler for `ReadPage`

Added: basic feed reader implementation + tests


The current configuration builder adds the YAML config file source last, causing it to override environment variables and command-line arguments. Fix the precedence so that environment variables and command-line arguments properly override the YAML config file. The intended order is: defaults (lowest) → YAML config file → environment variables → command-line arguments (highest).

Additionally, fix two other problems:

- The `EnvironmentVariables` provider does not clear its data before reloading, which can leave stale keys from a previous load. It also uses `OfType<DictionaryEntry>()` and assumes all keys are strings, throwing when non-string keys are present. Replace with a safe enumeration that clears data and skips keys that don't start with the prefix.

- In `InterfaceOptions`, `IntIp` and `ExtIp` parsing calls `IPAddress.Parse` on a possibly `null` configuration value, leading to a `NullReferenceException` when the key is absent. Fall back to `IPAddress.Loopback` if the value is missing.

implement correct configuration precedence


**Title:** Enable `ResultEmitter.NewPartition` to emit events on partition creation

**Context:**
In projections, partitions are discovered dynamically. Currently, `IResultEmitter.NewPartition` is `void` and does not emit any events when a new partition appears. We want to prepare the system to optionally emit events (e.g., partition‑created metadata) in the future without changing the caller‑emitter contract again. The `ResultEmitter` constructor also carries an unused `zeroTag` that can be cleaned up now.

**Request:**
1. Change `IResultEmitter.NewPartition(string partition, CheckpointTag at)` to return `EmittedEvent[]`.
2. In `ResultEmitter`:
   - Remove the `zeroTag` constructor parameter (it is no longer required).
   - Let `NewPartition` return `null` for now (no events emitted), but the signature allows future emission.
3. Update `NoopResultEmitter.NewPartition` to match the new signature; throw `NotImplementedException` as before (this path is never expected to be called).
4. In `CoreProjectionCheckpointManager.NewPartition`, call `_resultEmitter.NewPartition(...)` and forward the returned events if non‑null via `EventsEmitted(result)`.
5. Any existing callers that constructed `ResultEmitter` with the old two‑argument constructor must be updated to the single‑argument constructor.

**Acceptance Criteria:**
- `NewPartition` returns `EmittedEvent[]` instead of `void`.
- For `ResultEmitter`, the method returns `null` – no observable behavioural change in projections.
- The system handles the returned array correctly: when `null`, nothing is emitted; otherwise, the emitted events are processed by the checkpoint manager.
- No regressions in existing projection scenarios.

Changed: ResultEmitter NewPartition can emit events and ResultEmitter tests


**Bug: Multi-stream distribution point ignores pause when a read returns NoStream**

**Context**
The `MultiStreamReaderEventDistributionPoint` is used to read from several named event streams in parallel. It supports pausing the read process via `Pause()` and resuming via `Resume()`. When no events are available (stream is empty, end of stream, or the stream does not exist at all), the component normally schedules a delayed retry to pick up future events.

**Observed Behaviour**
After `Pause()` is called, if a read completion for a stream arrives with `RangeReadResult.NoStream` (the stream does not exist), the distribution point still emits a new `ReadStreamEventsForward` request (possibly delayed) and does **not** enter the paused state. This means the pause is ineffective – the component continues to request events from a non-existing stream in a loop, wasting resources and preventing a clean stop until a resume is triggered.

**Expected Behaviour**
- When `Pause()` has been requested (explicitly or due to external conditions), the distribution point must **not** emit any new read requests from any read completion, including `NoStream`.
- A `NoStream` result received while a pause is pending should:
  - Update the internal safe join position as usual for alignment,
  - Set the state to `paused` (so that a subsequent `Resume()` will start requesting again),
  - **Skip** scheduling the delayed re-read.

The same invariant should hold for all read completion outcomes: if pause is requested, no new `ReadStreamEventsForward` requests may be issued until an explicit `Resume()`.

**Acceptance Criteria**
1. Given a multi-stream distribution point with two streams, and stream B does not exist.
   When the distribution point is not paused and receives a `NoStream` result for B,
   Then it schedules a delayed re-read for B (current behaviour preserved).

2. Given a multi-stream distribution point that has already processed some events and is subsequently paused.
   When it then receives a `ReadStreamEventsForwardCompleted` for any stream with `RangeReadResult.NoStream`,
   Then it does **not** publish a new `ReadStreamEventsForward` request and transitions to the paused state.

3. The same pause-while-completing logic applies to other read results (e.g., empty Success) – no new reads are spawned while paused.

Fixed: multi-stream event distribution point continue requesting events from non-existing stream when pause requested


As a client of the Event Store projections HTTP API through the .NET Client API, I want the list operations (`ListAll`, `ListOneTime`, `ListContinuous`) to return a collection of structured projection detail objects instead of raw JSON strings. This will eliminate manual JSON parsing for every consumer and provide a clear contract for projection metadata.

### Acceptance Criteria

1. **Strongly-typed return values**
   `ProjectionsManager.ListAllAsync`, `ListOneTimeAsync`, and `ListContinuousAsync` return `Task<List<ProjectionDetails>>`.
   `ProjectionsClient` internal methods that serve these requests also return the same type.

2. **ProjectionDetails DTO**
   A sealed `ProjectionDetails` class exists in the `EventStore.ClientAPI.Projections` namespace. All its data is exposed through public, read-only fields (or properties) matching the JSON structure returned by the server. The fields include at least:
   `CoreProcessingTime`, `Version`, `Epoch`, `EffectiveName`, `WritesInProgress`, `ReadsInProgress`, `PartitionsCached`, `Status`, `StateReason`, `Name`, `Mode`, `Position`, `Progress`, `LastCheckpoint`, `EventsProcessedAfterRestart`, `StatusUrl`, `StateUrl`, `ResultUrl`, `QueryUrl`, `EnableCommandUrl`, `DisableCommandUrl`, `CheckpointStatus`, `BufferedEvents`, `WritePendingEventsBeforeCheckpoint`, `WritePendingEventsAfterCheckpoint`.

3. **JSON mapping**
   The implementation correctly deserializes the `"projections"` array from the server’s JSON response into `List<ProjectionDetails>`.
   When the response contains no `"projections"` property (or it is null), the result is `null` (or an empty list, consistently for all three methods).
   All three methods (`ListAll`, `ListOneTime`, `ListContinuous`) share the same mapping logic.

4. **Non-breaking behavior for other operations**
   Other projection management methods (`GetStatus`, `GetState`, `GetStatistics`, etc.) continue to return `string` and are unaffected. Authentication and timeout handling remain unchanged.

5. **External tooling compatibility**
   The `padmin` list command continues to work; it can output the new DTOs in a human-readable form (e.g., simple concatenation of their string representations), with no loss of information compared to the previous raw JSON output.

6. **Error handling**
   If the server returns a non-success status or an unexpected response format, the task faults as before (no silent swallowing of errors due to the deserialization step).

---
*The change is confined to the `ProjectionsManager` / `ProjectionsClient` public API surface and the new `ProjectionDetails` class.*

Implemented 494 story about mapping ClientApi queries to DTO objects


**Title:** ATOM feed returns empty document (200 OK) instead of 404 when navigating past the start of a stream

**Background**
When polling or walking backwards through a per-stream forward ATOM feed, a client may reach a page that contains no events (e.g., the stream is empty, or a “previous” link from the head feed leads beyond the first event). Currently, the HTTP API responds with `404 Not Found`, which breaks feed navigation and confuses clients that expect a consistent feed structure.

**Desired behaviour**
- For a per-stream, forward-direction ATOM feed request that reaches the logical start of the stream and has no events (i.e. `IsEndOfStream` is true and the event array is empty), respond with **`200 OK`** and an ATOM feed document instead of `404`.
- The returned feed document **must have an empty `entries` collection**.
- The **`previous` link must be omitted** (there is no earlier page).
- All other navigation links that would normally be present for a valid feed page (`self`, `first`, `last`, `next` when applicable) **must still be included**.
- The response **must not be cached**; set the `Cache-Control` header to:
  `max-age=0, no-cache, must-revalidate`.

**Scope**
This change applies only to per-stream forward feeds (e.g., `/streams/{stream}/head/backward/{count}` or explicit forward/backward URLs that resolve to a forward-direction feed). The `$all` stream feeds are unchanged.

**Rationale**
1. Consistent feed semantics: an empty feed page is a valid terminal state, not an error.
2. Avoids spurious `404` responses when polling the head or navigating toward the beginning of a stream.
3. The no-cache directive prevents clients from holding a stale empty page after new events are written.

change atom feed so on head when chasing an empty feed document with no


**Request:**
Change HTTP API behavior on non-master nodes when a client explicitly requires the master, and correctly handle link‑to resolution when reading the `$all` stream.

### 1. `ES-RequireMaster` handling on follower nodes (redirect instead of proxy)
When the client sets the header `ES-RequireMaster: True` on any request sent to a follower (non‑master) node, the follower **must** respond with HTTP status `307 Temporary Redirect` and a `Location` header pointing to the master node’s external HTTP endpoint.
The follower **must not** silently proxy/forward the request and return the master’s response; the client must be explicitly redirected so it can directly contact the master.
If `ES-RequireMaster` is missing or set to `False`, the follower may handle the request locally (e.g. reads) or continue to forward internally without a client‑visible redirect – the behavior for reads/writes in that case is unchanged.

*Applicable to all endpoints that accept the `ES-RequireMaster` header, including:*
- `POST /streams/{stream}` and `POST /streams/{stream}/incoming/{eventId}` (write events)
- `DELETE /streams/{stream}`
- `POST /streams/{stream}/metadata`
- `GET /streams/{stream}`, `GET /streams/{stream}/{event}`, and the forward/backward variants when `requireMaster` is parsed
- `GET /streams/$all` and its forward/backward variants when `requireMaster` is parsed

### 2. Respect `ES-ResolveLinkTos` when reading `$all`
When reading the `$all` stream (forward or backward), the server **must** respect the `ES-ResolveLinkTos` header:

- If the header is `True`, the response must contain the **resolved** events (original linked events), not the link‑to metadata events. Entries referencing a linked stream via a `$>` event should appear as if they belong to the original stream, and the `title` in the feed should reflect the original stream name.
- If the header is `False` or absent, the response must continue to show the unresolved link events exactly as they appear in the `$all` transaction log (the link metadata events).

This ensures the `$all` stream behaves consistently with how `ES-ResolveLinkTos` already works on regular stream reads.

### 3. CORS header spelling correction (minor)
The `Access-Control-Allow-Headers` response header must include `ES-RequireMaster` with the correct spelling (not `ES-RequiresMaster`), so that CORS preflight requests using the correct header name are permitted.

Return a temporary redirect if requiring master (#2028)


### Follower/replica failed to join cluster with “Data sizes violation” after initial flush on an ongoing chunk file

**Description**
When a follower/replica is joining a cluster, it opens the ongoing chunk file at a non‑zero write position.
If the first replication message does not contain a complete transaction, the node may issue a `Flush` before any record is appended.
This triggers a read‑to‑checksum operation inside `ChunkDataWriteStream` (because the internal write position was previously set and the stream needs to compute the incremental hash of the existing data).

The underlying stream used by `ChunkDataWriteStream` may be a buffered stream (e.g., `PoolingBufferedStream`).
After reading the existing data for checksumming, the stream’s internal read buffer is not fully drained.
A subsequent `Flush` discards those buffered bytes and advances the stream’s position to the end of the read buffer rather than to the correct write offset.
Future writes then land at the wrong file offset, and the node rejects them with a **“Data sizes violation”** error, preventing the node from joining the cluster.

This behaviour is a workaround for the way the buffered stream handles mixed read/write and flush operations.
There is no risk to data integrity – the chunk itself is not corrupted, only the runtime position tracking becomes inconsistent.

**Expected behaviour**
A follower/replica should join the cluster successfully even when the first replication message is smaller than a full transaction.
No “Data sizes violation” error should be raised in this scenario.

**Acceptance criteria**

- After `ChunkDataWriteStream` reads existing data to update its checksum (both synchronous and asynchronous write paths), the underlying file stream must be left in a state where its position equals the number of bytes that were checksummed, and no read‑buffer bytes remain that could be discarded by a flush.
- Calling `Flush` followed by `TryAppend` on the chunk must result in a successful append under the conditions described above.
- All existing chunk writing and verification behaviour must remain unchanged.
- The fix must be safe for concurrent use and not weaken the checksum or integrity guarantees.

**Notes**
The fix can be isolated to the `ChunkDataWriteStream` class. The problematic buffered‑stream behaviour is specific to the concrete stream implementation; a future update of that stream’s flush semantics may allow removing the workaround.

Fix "Data sizes violation" error (#5491)


## Bug: `fromStreamsMatching` filter has no access to stream metadata, preventing metadata-based stream exclusion

**Summary**
When using `fromStreamsMatching()` in a projection, the filter function cannot inspect stream-level metadata (e.g. `Skip`, `MaxCount`, `TruncateBefore`). Additionally, there is no way for the filter to cause a stream to be completely skipped; every matched stream currently generates a result, regardless of the filter’s intention.

**Steps to reproduce**
1. Create streams with stream metadata (e.g. `$$account-01` with `{"Skip":1}`).
2. Write a projection that uses `fromStreamsMatching` and attempts to exclude streams where `Skip` is set, for example:
   ```js
   fromStreamsMatching(function(s, e) {
       return !e.streamMetadata.Skip;
   }).when({ … })
   ```
3. Observe that the projection still produces results for the excluded streams, and that `e.streamMetadata` is always `undefined` inside the filter.

**Expected behavior**
- The event object passed to the `fromStreamsMatching` filter function should contain a `streamMetadata` property. This property must:
  - Be a parsed JavaScript object representing the stream’s metadata JSON (e.g. `{Skip:1}`), or an empty object if no metadata is present.
  - Be available during the catalog event transformation phase so the filter can make decisions based on it.
- The filter should be treated as a predicate: if it returns `false` (or a falsy value), the stream must be **entirely excluded** from the projection – no result stream should be emitted for it, and no spooling/processing should occur.
- If the filter returns `true` (or truthy), the stream should be included as before.

**Actual behavior**
- The `e` argument inside the filter provides event data and event metadata, but **no stream metadata**. Any attempt to read `e.streamMetadata` yields `undefined`.
- The filter’s return value is either ignored for exclusion purposes, or the filter is used as a transformer that directly returns a stream name. There is no documented (or working) way to prevent a stream from being processed further based on its metadata.

**Impact**
Projection authors cannot implement projections that conditionally skip streams according to their stream-level settings. This makes important use cases impossible, such as:
- Temporarily ignoring a stream marked with `Skip` in metadata during rebuilds.
- Filtering out system or test streams using custom metadata tags.
- Building projections that respect per-stream configuration without manual intervention.

The feature is effectively broken for any non-trivial filtering scenario that depends on stream metadata.

Fixed: fromStreamMatching() filtering based on streamMetadata


## Problem
When records are appended via the gRPC API with properties whose `google.protobuf.Value` entries have no variant set (i.e., an empty `Value` with `KindCase == None`), the write succeeds because protobuf treats this as technically valid. However, when the stored properties are later synthesized into JSON metadata (for projections, reads, etc.), the JSON formatter throws an exception ("Value message must contain a value for the oneof"). This unhandled throw can crash the server process—for example, when metadata is read on a projection core thread.

## Acceptance Criteria

**1. Reject invalid property values at the API boundary**
- Any gRPC append request that contains a property value with no variant set must be rejected before the write is persisted, with a clear validation error.
- The check must cover nested structures: if a `Value` is a `Struct` whose field values contain empty `Value` entries, or a `ListValue` whose elements contain empty entries, the request must be rejected.
- The error message should indicate that a property value is missing its type/variant.

**2. Survive existing invalid records without crashing**
- Records that have already been persisted with empty property values must not crash the server when read. The metadata synthesis path (`SynthesizeMetadataFromProperties`) must catch any exception during property-to-JSON conversion and produce a fallback JSON metadata blob that:
  - Is valid JSON.
  - Preserves the event type as the schema name (`$schema.name`).
  - Preserves the schema format (`$schema.format` as `"Json"` or `"Bytes"` according to the record’s `IsJson` flag).
  - Includes a designated error key (e.g. `$propertiesError`) with a message explaining that properties could not be rendered.

[DB-2154] Reject property values with no type set at the API boundary (#5653)


Report: **Projections V2 event-type filter is not enforced outside the stream/category dimension, leading to state corruption and checkpoint stalls**

**Observed behavior**
The projections V2 engine does not filter events by their declared type when a projection definition specifies `AllEvents: false` with an explicit `Events` list. The read-level filter only restricts by stream or category. As a result, events with types not listed in `Events` are delivered to the state handler. When the handler has no matching rule, the default handling path overwrites partition state with the raw event body, corrupting accumulated state.

Additionally, the engine's checkpoint position does not advance past filtered-out event types. If a stream contains a long tail of events that are not in the declared `Events` list, no checkpoint is emitted for that tail. On restart, the same large block of irrelevant events must be re-read, causing unnecessary replay work.

**Expected behavior**
1. Events whose type is not listed in `Events` when `AllEvents: false` must never reach the state handler. They should be silently dropped before conversion and dispatch, mirroring the behaviour of the V1 `EventFilter.Passes` contract.
2. The read loop must still advance its internal log position and count bytes for filtered events so that long runs of non-matching events can satisfy checkpoint thresholds (e.g., `CheckpointUnhandledBytesThreshold`) and produce a checkpoint that moves past them.
3. The final checkpoint at engine stop must be emitted when the read position has advanced, even if no events were dispatched, as long as unhandled bytes were processed.
4. If `AllEvents` is `false` but the `Events` array is `null`, the engine must fail fast with a clear error rather than silently discarding every event.

**Impact**
- **State corruption**: Partitioned projections silently lose their state when an unhandled event type passes through.
- **Operational load**: Checkpoints lag behind large tails of non-matching events, forcing expensive re-reads on every restart.
- **Misconfiguration silently ignored**: A missing `Events` list leads to all events being dropped without any indication.

**Context**
Projections V2 engine, source definition (`IQuerySources`, specifically `AllEvents` and `Events`), state-handling path (`Handle` in Jint/V8), and checkpoint coordination (`CheckpointCoordinator`).

[DB-2034] Projections V2: filter events by declared type (#5587)


In `Enumerators.AllSubscriptionFiltered`, the `ClientMessage.FilteredSubscribeToStream` is published with `checkpointInterval` set to the raw `checkpointIntervalMultiplier`. The intended behavior is to use `checkpointIntervalMultiplier * maxSearchWindow` as the actual interval so that checkpoint frequency aligns with the search window.

Additionally, duplicate checkpoint notifications can fire when the same position is reached more than once. The enumerator should only invoke the checkpoint callback when the checkpoint position is strictly greater than the last notified position.

Adjust `AllSubscriptionFiltered` to:
- compute `_checkpointInterval = checkpointIntervalMultiplier * _maxSearchWindow` and pass that value to the subscription message,
- track the last notified checkpoint position and suppress duplicate notifications.

use checkpointInterval instead of checkpointIntervalMultiplier in filtered subscriptions


We need a new authentication provider for HTTP requests that trusts an upstream proxy or middleware component. The provider should authenticate a user based on the value of a custom header, `X-ES-TrustedAuth`. This will allow deployments where a reverse proxy handles the actual authentication and then forwards the resolved identity and group memberships to Event Store without re‑authenticating.

**Expected behavior**

1. **Header format**
   `X-ES-TrustedAuth: <username>[; <group1>, <group2>, …]`
   The header value consists of a login name optionally followed by a semicolon and a comma‑separated list of groups. Whitespace around each part should be trimmed.

2. **Authentication chain**
   - The new trusted provider must be evaluated **after** `BasicHttpAuthenticationProvider` and **before** `AnonymousAuthenticationProvider` in the existing chain.
   - If the header is present and correctly formatted, the provider authenticates the request immediately and sets the principal with the given login and groups. The login itself should be added as an additional role (e.g., the principal’s role list includes all groups plus the login).
   - If the header is present but malformed (e.g., more than one semicolon, empty parts, etc.), the provider **must respond with 401 Unauthorized** and not fall through.
   - If the header is absent entirely, the provider must return `false`/fall through so that the next provider (Anonymous) can be evaluated.

3. **Principal construction**
   The principal is a `GenericPrincipal` with a `GenericIdentity` using the login as the name, and the roles array containing the trimmed groups (if provided) plus the login as the last element. If no groups are given, the roles array contains only the login.

**Constraints & safety**

- **No credentials validation**: The provider trusts the header completely; there is no password check or user store lookup. It is intended only for environments where the HTTP connection to Event Store is not exposed directly to clients but only to a trusted proxy/middleware.
- **Early 401**: Malformed header values must never fall through to the next provider—they must result in an immediate 401 response to prevent open access via a fuzzed header.
- **Integration point**: The new provider should be instantiated and placed into the `_providers` array in `HttpService` at the correct position, without requiring any additional configuration file or startup parameter (it is always active once compiled in, relying on network topology for safety).

Please implement a `TrustedAuthenticationProvider` that satisfies the above and wire it into the HTTP service’s authentication pipeline.

Added: TrustedAuthenticationProvider - very straightforward approach


Remove the projection-based user indexing and instead write user-link events directly into the `$users` stream when a user is created. This eliminates a race condition during node startup where the REST API can return an empty user list until the `$users` projection catches up.

**Acceptance Criteria**
- After a new user is successfully created through the admin API, the user’s login name immediately appears when listing all users (via HTTP or the client API), without waiting for any projection to process events.
- The initial `admin` user created during first startup is also included in the user list.
- The existing HTTP and client user-list APIs continue to work with the same response shape (login name, full name, groups, …).
- The `IndexUsersProjectionHandler` and `UserManagementProjectionsRegistration` classes are removed; no projection is involved in user indexing.
- User creation, update, enable, disable, password changes, and deletion continue to behave as before and are not affected.
- The `$users` stream is written to directly by the user management service (only when a user is created), and the `AllUsersReader` can consume it without changes to its stream-reading logic.

Merge pull request #349 from EventStore/usernoprojection