Ship sqlite3 worker so npm consumers can use the command (#190)

The sqlite3 command was broken when consumed via the published npm
tarball: `findWorkerPath()` falls through to `<chunks>/worker.js` (the
python3 worker, which `build:worker` placed there), causing every
sqlite3 invocation to fail with "Expected ArrayBuffer for the first
argument" on protocol mismatch. The bug was invisible in this repo
because `tsc` emits `dist/commands/sqlite3/worker.js` locally before the
buggy fallback is reached, but the `files` allowlist excluded that path
from the tarball.

Mirror the js-exec worker pattern: bundle the sqlite3 worker, place it
at `dist/commands/sqlite3/worker.js`, `dist/bin/chunks/sqlite3-worker.js`,
and `dist/bundle/chunks/sqlite3-worker.js`, and ship the first one in
`files`. Update `findWorkerPath()` to prefer the uniquely-named
`sqlite3-worker.js` chunk and gate the bare `<currentDir>/worker.js`
lookup on the directory actually being `commands/sqlite3` so the silent
fallback to a wrong-command worker can't return. Add a unit test that
pins the resolution order and would have caught the original bug.

Also wire sqlite3 into `check-worker-sync.js` so the bundled worker
stays in sync with `worker.ts`, and exclude the generated artifact from
biome / banned-patterns lints (matching the existing python3 / js-exec
treatment).

Verified end-to-end by `npm pack` + install in a clean consumer:
sqlite3 now executes successfully without any post-install patching.

Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>