chore: resync package-lock.json root metadata to @lannguyensi/codebase-oracle@0.6.1

[LanNguyenSi]

Why

After PR #37 (scope rename) and PR #38 (0.6.1 hotfix), package-lock.json root metadata was never re-generated. Both the top-level name/version and the packages[""] entry still pointed at the unscoped codebase-oracle@0.5.0. npm publish was unaffected (it reads package.json), but tooling that keys off the lockfile root (sbom generators, audit reports, CI cache keys, IDEs) saw stale values, and anyone running npm install after a git pull would have produced an uncorrelated diff on the next PR.

What

In-place edit of the four root metadata fields:

-  "name": "codebase-oracle",
-  "version": "0.5.0",
+  "name": "@lannguyensi/codebase-oracle",
+  "version": "0.6.1",
   ...
   "packages": {
     "": {
-      "name": "codebase-oracle",
-      "version": "0.5.0",
+      "name": "@lannguyensi/codebase-oracle",
+      "version": "0.6.1",

That is the entire diff: 1 file, +4/-4. No dep version churn.

Why in-place edit instead of rm && npm install

The lockfile was last written 2026-05-11. Caret-ranged direct deps (@langchain/*, commander, etc.) could float to current registry state on a fresh install, producing an unrelated cascade. The four root metadata fields are pure name/version copies from package.json: per npm v3 lockfile docs, the root packages[""] entry carries no integrity, _id, _from, _resolved, or workspaces field, so editing them in place is equivalent to a fresh regenerate without the caret-float risk.

Smoke (local)

$ npm ci                                # 67 packages, 0 vulns
$ node -e "const D=require('better-sqlite3'); const v=require('sqlite-vec'); const db=new D(':memory:'); v.load(db); ..."
sqlite-vec v0.1.9                       # CI's native-deps guard passes
$ npx tsc --noEmit                      # clean
$ npx vitest run                        # 172/172 passing
$ node -p "require('./package-lock.json').packages[''].name"
@lannguyensi/codebase-oracle

Future drift is loud

The npm-publish workflow runs npm ci (line 59) BEFORE the tag-version guard (line 61). A future package.json version bump without a matching lockfile bump fails npm ci with "Invalid: lock file's @lannguyensi/codebase-oracle@X.Y.Z does not satisfy ...", so the drift cannot silently slip into a release.

Out of scope (potential follow-up)

The reviewer flagged: no PR-time CI check for lockfile-vs-package.json sync. Drift currently surfaces at release time, not at the PR that introduces it. Worth a separate task if we want a tighter loop.

Review

Internal review subagent (general-purpose): LGTM. Confirmed lockfile v3 root entry has no integrity/_id/workspaces fields; npm ci is the dispositive validator.