eslint --fix produces output that prettier --check rejects

[rubenvdlinde]

Running this repo's own lint fixer produces a file this repo's own format check
rejects. So fixing lint the documented way lands a red Frontend Check (format).

Reproduce

On a clean development:

npx eslint tests/e2e/sbom-import.spec.ts --fix
npx prettier --check tests/e2e/sbom-import.spec.ts
# [warn] tests/e2e/sbom-import.spec.ts
# [warn] Code style issues found in the above file.

What they disagree about

eslint --fix writes:

import type {Page} from '@playwright/test';

prettier --check demands:

import type { Page } from '@playwright/test'

Different brace spacing, different semicolon policy. Neither is wrong on its own
— they are configured independently and nothing reconciles them.

I hit this for real: a PR went red on Frontend Check (format) for a file whose
only substantive change was a Playwright locator. The format failure had nothing
to do with the change; it came from having run eslint --fix on the same file.

A second, separate disagreement in the same area

import-extensions/extensions wants .ts on relative imports:

The relative import should probably have the file extension ".ts"

No relative import in any e2e spec complies — 0 of 6 files. So this rule is
currently at odds with the entire codebase rather than flagging a defect in any
one file. Complying in a single file would make that file the inconsistent one.

Why this is worth a decision rather than a drive-by fix

Both are config questions with more than one defensible answer:

• run prettier as an eslint rule (eslint-plugin-prettier) so one tool wins, or
• keep them separate and align the overlapping options by hand, or
• for the second: either adopt .ts extensions repo-wide, or turn the rule off
  because this codebase has decided against them

Whichever is chosen should be applied repo-wide in one pass, not settled
file-by-file inside unrelated PRs. Filing rather than fixing, because picking one
silently inside a locator fix would be exactly the wrong place for it.

Context

Found in #734 (closed — the locator bug it fixed was already
solved on development by a better change). This part had no other home.