fix(auth): pin Better Auth to 1.6.25

[shoveller]

Description

Prevents fresh @sonicjs-cms/core consumers from resolving Better Auth 1.7.x before SonicJS has migrated its auth_account schema to the new issuer-scoped account identity model.

Fixes #1061

• Fork issue: fix(auth): prevent Better Auth 1.7 from resolving in new consumers illuwa-soft/sonicjs#1
• Fork review: fix(auth): pin Better Auth to 1.6.25 illuwa-soft/sonicjs#2

Changes

• Pin better-auth, @better-auth/core, @better-auth/drizzle-adapter, and @better-auth/telemetry to the repository-tested 1.6.25 release.
• Keep the root and standalone core lockfile manifest snapshots aligned with the published core manifest.
• Add a deterministic regression test requiring the complete Better Auth family to use one exact schema-compatible version.
• Ignore the repository-local .worktrees/ directory used for isolated contribution work.

@better-auth/core is intentionally direct: a packed-consumer check showed that pinning only the other three packages still allowed peer dependency resolution to install @better-auth/core@1.7.1 alongside 1.6.25.

This urgent patch does not change the database schema or runtime auth code. A coordinated Better Auth 1.7 issuer migration remains follow-up work.

Testing

Unit Tests

• Added better-auth-dependency-compat.test.ts
• Verified the test fails with the previous caret ranges
• Targeted regression test passes
• Full unit suite passes: 110 files passed, 6 skipped; 1,731 tests passed, 247 skipped
• Coverage suite passes with the same test totals

Package Consumer Check

• Packed packages/core with npm pack
• Installed the tarball into a fresh temporary consumer using --package-lock-only
• Confirmed exactly one resolved version of each package, all 1.6.25:
  • better-auth
  • @better-auth/core
  • @better-auth/drizzle-adapter
  • @better-auth/telemetry

Other Verification

• npm run lint --workspace=@sonicjs-cms/core (passes with existing warnings)
• npm run type-check
• npm run build:core
• git diff --check
• New Playwright spec: not applicable because this patch changes package resolution only; existing auth E2E behavior is unchanged

Known Repository Baseline Issue

npm ci --ignore-scripts currently fails before installation because the checked-in root lockfile already drifts from unrelated workspace manifests (esbuild, eslint, and sharp). The repository CI uses npm install, which succeeds. This PR deliberately avoids including the resulting 1,500+ lines of unrelated lockfile churn.

Screenshots/Videos

Not applicable; no UI changes.

Checklist

• Code follows project conventions
• Tests added and passing
• Type checking passes
• No new console errors or warnings
• Documentation update not required for this compatibility pin
• No migration or fixture changes

[mmcintosh]

Confirming this fix targets a live, repo-wide CI problem — with a reproduction and the concrete mechanism.

Root cause, reproduced. packages/core/package.json carries "better-auth": "^1.6.13" (and the scoped packages at ^1.6.23). With no lockfile constraint — i.e. a fresh install, which is exactly what the CI preview deploy and any new @sonicjs-cms/core consumer do — that caret resolves to the current latest, 1.7.1:

$ echo '{"dependencies":{"better-auth":"^1.6.13"}}' > package.json && npm i --package-lock-only
# → better-auth 1.7.1
$ echo '{"dependencies":{"better-auth":"1.6.25"}}' > package.json && npm i --package-lock-only   # this PR's pin
# → better-auth 1.6.25

The committed lockfile currently pins the family to 1.6.22, so local npm ci passes while any fresh resolve floats to 1.7 — a classic works-locally / breaks-on-fresh-install split.

Why 1.7 breaks auth specifically. better-auth 1.7.0 ships breaking schema changes — most relevantly "Accounts now require Account.issuer… Must apply account-identity backfill before deploying", plus the joins-config move that "requires regenerating schemas." SonicJS's 0001_core.sql was written for 1.6.x: auth_account has account_id/provider_id but no issuer column (and no backfill). So under 1.7 the account/session/login operations hit a mismatched schema and fail at runtime, while non-auth routes are unaffected.

Observed impact. On the shared PR preview lane this shows up as a consistent block of @auth/session failures — 02c-otp-login, 02d-magic-link-auth, 38/68/80-user-profile*, 85-admin-panel-roles, 02-authentication, 67-rbac — on PRs otherwise unrelated to auth. I hit exactly this set on a templates-only PR (#1066), and the failures were invariant across a test-only re-push, i.e. not caused by that PR. Same root cause as #1054 (can't log in on a fresh production deploy).

Pinning the whole family to an exact, schema-compatible 1.6.25 (+ the guard test here) is the right fix. It looks stalled, though: the authorize check is still pending (external-contributor workflow authorization), so CI hasn't run, and there's no review yet. Authorizing + landing this should green the @auth E2E lane across every open PR.

(Reproduced locally; I did not run the auth E2E under 1.7 — that path needs the preview deploy — but the resolution float and the 1.7 schema break are both verified above.)