style(eslint): enable prefer-optional-chain rule - #12331

Description

The PR enables @typescript-eslint/prefer-optional-chain as an error for all **/*.ts, but there
are still x && x.y patterns (e.g., this.options && this.options.data/reload/chunk) that the rule
will flag, causing npm run lint to fail.

Code

eslint.config.mjs[40]

+            "@typescript-eslint/prefer-optional-chain": "error",

Evidence

ESLint is run repo-wide via npm run lint, and the new rule applies to all TS files. The current
branch still contains classic null-check && chains that match what prefer-optional-chain targets
(same base repeated with member access), so flipping the rule to error will introduce new lint
failures.

eslint.config.mjs[31-41]
package.json[78-91]
src/persistence/EntityPersistExecutor.ts[46-69]
src/persistence/SubjectExecutor.ts[431-476]
src/persistence/SubjectExecutor.ts[587-600]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`@typescript-eslint/prefer-optional-chain` is now an **error**, but there are still `&&`-based null checks in the repo that will be reported by the rule (and fail `npm run lint`).

## Issue Context
The eslint flat config applies to `files: ["**/*.ts"]`, and `package.json` runs `eslint` without path restrictions.

## Fix Focus Areas
- Replace `this.options && this.options.data` with optional chaining (or an explicit undefined check if falsy values must be preserved).
- Replace `this.options && this.options.reload === false` with `this.options?.reload === false`.
- Refactor the chunk logic to avoid `this.options && this.options.chunk && this.options.chunk > 0` (e.g., store `const chunk = this.options?.chunk` and use `chunk && chunk > 0`).

### Files/lines to update
- eslint.config.mjs[31-41]
- package.json[78-91]
- src/persistence/EntityPersistExecutor.ts[46-69]
- src/persistence/SubjectExecutor.ts[431-476]
- src/persistence/SubjectExecutor.ts[587-600]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

OrmUtils.parseSqlCheckExpression uses if (enumMatch?.index) which skips valid matches at offset
0, preventing enum parsing when the CHECK-expression pattern starts at the beginning of the SQL
string.

Code

src/util/OrmUtils.ts[324]

+        if (enumMatch?.index) {

Evidence

String.match() sets match.index to 0 when the match is at the beginning; checking `if
(enumMatch?.index) treats 0` as falsy and incorrectly bypasses the parsing logic even though a
match exists.

src/util/OrmUtils.ts[314-327]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`parseSqlCheckExpression` incorrectly uses a truthiness check on `enumMatch.index`, which fails when `index === 0`.

## Issue Context
When a regex match is at the start of the string, `match.index` is `0`.

## Fix Focus Areas
- Change the condition to an explicit undefined check, e.g. `if (enumMatch?.index !== undefined)` (or `!= null`).

### Files/lines to update
- src/util/OrmUtils.ts[314-327]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools