This is a comment left during a code review.
Path: CHANGELOG.md
Line: 183-191

Comment:
**Unresolved merge conflict markers**

`CHANGELOG.md` still contains raw Git conflict markers (`<<<<<<< Updated upstream`, `=======`, `>>>>>>> Stashed changes`). These need to be resolved before merging — any tooling that parses `CHANGELOG.md` (release scripts, changelog generators, etc.) will fail or produce malformed output, and the conflict markers will appear verbatim in the published file.

The resolution should keep both the pre-existing entries from upstream **and** the new SQLite transient-handling entry from this PR, removing all three conflict delimiters.

How can I resolve this? If you propose a fix, please make it concise.

---

This is a comment left during a code review.
Path: src/infra/unhandled-rejections.ts
Line: 256-260

Comment:
**`errno` fallback may produce false positives**

The fallback to `errno` after `errcode` is checked means a non-SQLite error object that happens to have a numeric `errno` of `5`, `6`, `10`, or `14` will be silently swallowed as a "transient SQLite error." In Node.js, system errors typically carry **negative** `errno` values (e.g. `-5` for EIO), so the risk is low in practice, but third-party libraries occasionally surface raw POSIX errno values as positive integers — and `5` (EIO), `6` (ENXIO), `10` (ECHILD), and `14` (EFAULT) are valid POSIX constants that could collide with `TRANSIENT_SQLITE_ERRCODES`.

Consider restricting the numeric check to `errcode` only, which is the node:sqlite-specific field, and drop the `errno` fallback for numeric matching:

```suggestion
    const sqliteErrcode = extractNumericErrorCode(candidate, "errcode");
    if (sqliteErrcode !== undefined && TRANSIENT_SQLITE_ERRCODES.has(sqliteErrcode)) {
```

How can I resolve this? If you propose a fix, please make it concise.

---

This is a comment left during a code review.
Path: src/infra/unhandled-rejections.ts
Line: 88-90

Comment:
**`"database schema is locked"` snippet does not match a real SQLite message**

The standard SQLite error for a schema change is `"database schema has changed"` (associated with `SQLITE_SCHEMA`, error code 17), not `"database schema is locked"`. As written, this snippet will never match any real SQLite error message and is effectively dead code. If the intent is to catch `SQLITE_SCHEMA` retries, the snippet should be corrected — though `SQLITE_SCHEMA` (a prepared-statement invalidation) is arguably not in the same category as the transient lock/IO errors being handled here.

```suggestion
  "disk i/o error",
```

How can I resolve this? If you propose a fix, please make it concise.