Four TypeScript errors were tripping the workflow's type-check step:

- `ai-assistant.ts`: drop the `_unsubCommands` field. It was assigned
  in the constructor but never read, so `noUnusedLocals` flagged it.
  The panel is a page-lifetime singleton; `subscribeCommands()` can
  run for side-effect only and die with the page.
- `ai-assistant.ts`: rename the unused `cmd` parameter in
  `_renderCommandResult` to `_cmd` so it clears `noUnusedParameters`.
- `ai-assistant.ts`: the silent-success branch called a
  non-existent `this._clearResults()`. Replace with the two-line
  clear+hide inline — that matches how every other branch in the
  file shows/hides `_resultsEl`.
- `types.ts`: `NativeWindowDef` inherited `x`/`y` as required from
  `WindowConfig`, but `NativeWindowServerEntry` never supplies them
  and `createRegisterWindow` already nullish-coalesces with `?? 0`.
  Omit `x`/`y` from the `extends` clause and redeclare them as
  optional — the type now matches the runtime.

The old lockfile held only macOS-arm64 entries for `@esbuild/*`, so
CI's Linux runner couldn't resolve them and `npm ci` bailed with
"Missing: @esbuild/linux-x64@0.28.0 from lock file" (and 20+ more).
A clean `npm install` writes the lockfile with every platform's
optional binary, which is what npm 7+ expects.

Same fix as fix/php-tests 66cc8c5 — `npm install` on Node 24 / npm
11 leaves ~28 `@esbuild/<platform>` optional-binary entries marked
`"extraneous": true` in the lockfile. CI's `npm ci` (Node 20)
refuses those because the platform metadata doesn't match Linux
x64, even though they're nominally optional. `npm prune` drops the
extras cleanly.

Replace the previous Mac-generated (and partially-pruned) lockfile
with one written by npm 10 on node:20-alpine via Docker. That matches
CI's runtime exactly, so `npm ci` on the Linux runner stops choking
on stray `"extraneous": true` entries and missing platform binaries.

Verified locally via `npm ci` (read-only install from this lockfile)
on macOS — Vitest all-green, lockfile unchanged.

…dentation

The WP/ESLint indent rule has JSX-aware smarts that preserve ternary
indentation in `prop={ cond ? x : y }` shapes, but no equivalent for
tagged-template DSLs. Inside `` html`...${ cond ? x : y }...` `` it
treats the interpolation as a plain JS ConditionalExpression and
aligns it to the enclosing block — which flattens ternaries against
the left margin and loses the author's visual alignment with the
surrounding template.

Add `ignoredNodes: [ 'TemplateLiteral *' ]` to the indent rule so
ESLint stops reformatting content inside template literals. Also add
`SwitchCase: 1` (the WP convention) while we're there to match
what's expected in regular switch statements.

Then restore the visually-nicer ternary indentation that the first
`eslint --fix` run flattened in the affected src/ files.

Also gitignore /vendor so the Composer deps (for PHP tests on the
other branch) don't accidentally get staged.

No runtime change. ~360 Vitest tests still green; `tsc --noEmit`
still clean.