fix(deploy): deploy worker before d1 migrations

[JSONbored]

Motivation

• The migrations added a destructive ALTER TABLE ... DROP COLUMN private_trust_enabled which creates a deployment-time window if remote D1 migrations are applied before the new Worker is active, causing older Worker code to crash when it still expects the dropped column.
• The intent is to avoid that availability regression by ensuring the new Worker binary is deployed before applying destructive remote migrations.

Description

• Change the deploy:api NPM script to run wrangler deploy before wrangler d1 migrations apply ... --remote so the Worker is upgraded prior to applying DB migrations.
• Regenerate the Worker runtime type file (worker-configuration.d.ts) via the cf-typegen step so the local cf-typegen drift check remains green with the updated Wrangler/runtime output.

Testing

• Ran git diff --check, which reported no whitespace/conflict issues.
• Ran npm run db:migrations:check, which passed against the migration set (no gaps/duplicates).
• Ran npm run cf-typegen, which regenerated worker-configuration.d.ts and made the cf-typegen:check parity pass locally.
• Ran npm run test:ci, which exercised the CI gate but failed due to unrelated unit-test issues in test/unit/queue.test.ts (stack-depth/timeouts), not related to the deployment-sequencing script change, and npm audit --audit-level=moderate failed with a registry 403 Forbidden from the audit endpoint.

---

Codex Task

[superagent-security]

Superagent didn't find any vulnerabilities or security issues in this PR.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 93.65%. Comparing base (1ec9f94) to head (7eed03a).
⚠️ Report is 1 commits behind head on main.
✅ All tests successful. No failed tests found.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #4113   +/-   ##
=======================================
  Coverage   93.65%   93.65%           
=======================================
  Files         384      384           
  Lines       35865    35865           
  Branches    13160    13160           
=======================================
  Hits        33589    33589           
  Misses       1618     1618           
  Partials      658      658           

🚀 New features to boost your workflow:

• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[loopover-orb]

Warning

🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨

⏸️ Gittensory review result - manual review recommended

_{Review updated: 2026-07-08 03:34:18 UTC}

1 file · 1 AI reviewer · 2 blockers · readiness 93/100 · CI green · clean

⏸️ Suggested Action - Manual Review

• No linked issue detected — If this PR is intended to solve an issue, link it explicitly in the PR body.
• Maintainer requires a linked issue — Link the relevant issue (for example Closes #123) before opening the PR.

Review summary
This flips deploy:api's script order so `wrangler deploy` runs before `wrangler d1 migrations apply --remote`, closing the availability window where old Worker code (still expecting a column a destructive migration is about to drop) could crash mid-deploy. The reasoning is sound for this specific DROP COLUMN migration, but the script is shared by all future deploys and the new fixed ordering silently assumes every future migration is contract-style (removal); an additive migration where new Worker code needs a not-yet-existing column would hit the inverse problem. The diff itself is a correct, minimal, low-risk one-line change.

Nits — 4 non-blocking

• package.json:16 — the new worker-first ordering only holds for destructive/contract-style migrations; consider a comment noting this assumption so a future additive migration doesn't silently reintroduce the same class of deploy-window bug in the opposite direction.
• The PR description says worker-configuration.d.ts was regenerated via cf-typegen, but no such file appears in the diff — worth a one-line clarification that there was no drift to commit, so reviewers don't read it as an unlanded scope item.
• Document the expand/contract deploy convention (worker-first for drops, migrate-first or split-migration for additive changes) near deploy:api so this ordering decision isn't re-litigated per PR.
• If destructive migrations become common, consider splitting deploy:api into an explicit two-step (deploy, then a separate post-deploy migrate step) with a comment cross-referencing which migrations are safe in which order.

Concerns raised — review before merging

• No linked issue detected — If this PR is intended to solve an issue, link it explicitly in the PR body.
• Maintainer requires a linked issue — Link the relevant issue (for example Closes #123) before opening the PR.

Signal	Result	Evidence
Code review	❌ 2 blockers	1 reviewer
Linked issue	⚠️ Missing	No linked issue or no-issue rationale found.
Related work	✅ No active overlap found	No same-issue or scoped active PR overlap found.
Change scope	✅ 20/20	Low review scope from cached public metadata (no linked issue context).
Validation posture	✅ 25/25	PR body includes validation/test evidence.
Contributor workload	✅ 10/10	Author activity: 51 registered-repo PR(s), 43 merged, 505 issue(s).
Contributor context	✅ Confirmed Gittensor contributor	JSONbored; Gittensor profile; 51 PR(s), 505 issue(s).
Gate result	❌ Blocking	Repo-configured hard blocker found.

Review context

• Author: JSONbored
• Role context: owner (maintainer lane)
• Public audience mode: oss maintainer
• Lane context: Repository is configured for direct PR review.
• Public profile languages: Python, TypeScript, JavaScript, Ruby, Go, Kotlin, MDX, Shell
• Official Gittensor activity: 51 PR(s), 505 issue(s).
• PR-specific overlap: none found.

Contributor next steps

• Treat this as maintainer-lane context rather than normal contributor-lane activity.
• Explain no-issue PR.
• Link the issue being solved, or explicitly explain why this is a no-issue PR.

Signal definitions

• Related work = same linked issue, overlapping active PRs, or title/path similarity.
• Change scope = cached public metadata such as size labels, draft state, and review-burden hints.
• Validation posture = whether the PR provides enough public validation/test evidence for maintainer review.
• Contributor workload = public contributor activity and cleanup pressure, not a repo-wide quality failure.
• Contributor context = public GitHub/Gittensor identity context; non-Gittensor status is not a blocker.

_{🟩 Safe / merged · 🟦 Advisory · 🟨 Held for review · 🟥 Blocked / closed}

---

💰 Earn for open-source contributions like this. Gittensor lets GitHub contributors earn for the work they already do — register to start earning →.

Checked by Gittensory, a quiet PR intelligence layer for OSS maintainers.

• Re-run Gittensory review