chore: dependency maintenance + repair the CI workflow

[ucjonathan]

Summary

Two pieces of maintenance. No source, no package.json, no public API change.

1. Dependencies — clears a high-severity advisory. Lockfile-only.
2. CI — repairs a workflow that has never successfully run.

1. Dependencies

Package	From	To	Why
brace-expansion	1.1.15	1.1.18	Clears a high-severity DoS advisory set
ultra_cart_rest_api_v2	4.1.103	4.1.125	Lockfile pin was behind the declared range

npm audit reported one high-severity finding — GHSA-3jxr-9vmj-r5cp (exponential-time expansion), GHSA-mh99-v99m-4gvg (OOM crash), GHSA-rgw5-rvv9-x895 (bypass of the CVE-2026-14257 mitigation). Reachability is dev-only:

ultra_cart_rest_api_v2 (devDependency / optional peer)
  └─ @babel/cli → glob@7 → minimatch@3 → brace-expansion@1.1.15

npm audit --omit=dev was already clean beforehand, and files ships only src/ + CHANGELOG.md, so no published install of @ultracart/bigquery-sdk was ever exposed. Hygiene for local dev and CI, not a consumer-facing vulnerability.

No package.json change: ^4.1.103 already permits 4.1.125, so npm update moved the lockfile alone. Deliberately not tightening the peerDependencies range — that would force an upgrade on consumers for no benefit. Runtime dependency set is untouched (@google-cloud/bigquery only).

2. CI repair

.github/workflows/ci.yml gated its BigQuery auth step on:

        if: ${{ secrets.GCP_SA_KEY != '' }}

The secrets context is not available in if conditions, and a single invalid expression invalidates the entire workflow file. Consequence: every CI run since the repo's first commit failed in 0s with "workflow file issue", and the unit tests never ran on any push or PR — including on the v0.1.0 release commit.

failure  ci.yml  main                      0s   2026-06-30
failure  ci.yml  main                      0s   2026-06-30
failure  ci.yml  setup-trusted-publishing  0s   2026-06-30

The job could not have worked in any case: GCP_SA_KEY was never configured — this repo has no secrets or variables set at all — so it was gating on a credential that doesn't exist while taking the test suite down with it.

This removes the job rather than repairing the guard. CI is now checkout → install → npm test, and it runs. The weekly cron goes with it; its only stated purpose was the drift check. ci.yml now contains no ${{ }} expressions, so there is nothing left that can silently invalidate it.

The drift check is unaffected — it still runs locally via npm run check:schema, exactly as CONTRIBUTING.md documents. A follow-up can return it to CI using the script's existing credential-free --schema-dir offline mode against committed schema snapshots, in its own workflow so it can never take the unit tests down again. That's preferable to putting a long-lived service-account key in a public repo's secrets, and consistent with how publish.yml already avoids long-lived tokens via OIDC.

Verification

• npm audit → 0 vulnerabilities (was 1 high)
• npm test → 20/20 passing, matching the pre-change baseline
• CI green on this PR — the first passing run this repo has had
• Lockfile diff is 6 lines: two version/resolved/integrity triples

Deliberately out of scope

• @google-cloud/bigquery 8.3.1 → 9.0.1 — major bump on the one runtime dependency. Needs its own reviewed PR.
• npm ci || npm install — the fallback silently ignores the committed lockfile. Worth tightening to plain npm ci, but left alone here to keep this PR's CI change minimal.
• Live schema-drift verification — the SDK bump (4.1.103 → 4.1.125) may add model fields that widen the SDK-only set against the warehouse schema. Worth running npm run check:schema against a real dataset before the next release.

🤖 Generated with Claude Code