chore(comments): re-point dangling supabase/migrations breadcrumbs

The Supabase purge deleted the archived supabase/migrations/.archived/
directory, but 12 src/ files still referenced its files by path in
JSDoc / TODO comments. The references were misleading (pointing to
deleted files), so re-point them at the canonical location of those
RPCs in db/migrations/0001_init.sql. No code or behavior changes.

Also fixed a stray 'supabase shim returns empty results' comment in
src/app/admin/page.tsx (the shim was already removed in Step 3 of
the refactor).

src/actions/analytics.ts

@@ -68,9 +68,10 @@ export type ConversionFunnel = {
 
 /**
  * Aggregate KPIs over a date window. Replaces the
- * `get_reports_summary` SECURITY DEFINER RPC from
+ * `get_reports_summary` SECURITY DEFINER RPC (originally from the now-
- * `supabase/migrations/031_reports_v1_rpcs.sql`. Returns zeroed metrics
+ * archived supabase migrations; consolidated into
- * if the caller is unauthenticated or no orders exist in the window.
+ * `db/migrations/0001_init.sql`). Returns zeroed metrics if the caller
+ * is unauthenticated or no orders exist in the window.
  */
 async function getReportsSummary(
   brandId: string | null,

src/actions/import-orders.ts

@@ -11,8 +11,9 @@ export type ImportOrdersResult =
 
 /**
  * Bulk-import orders. Replaces the legacy `create_order_with_items` SECURITY
- * DEFINER RPC (`supabase/migrations/021_shipping_only_brand.sql`). The new
+ * DEFINER RPC (originally from the now-archived supabase migrations;
- * `orders` schema doesn't have `subtotal`, `customer_name`, `customer_email`,
+ * consolidated into `db/migrations/0001_init.sql`). The new `orders`
+ * schema doesn't have `subtotal`, `customer_name`, `customer_email`,
  * `customer_phone`, or `stop_id` columns — totals are stored in
  * `total_cents` and customers are referenced by `customer_id`. For each
  * imported order we upsert a `customers` row keyed on email+tenant, then

src/actions/reports.ts

@@ -73,7 +73,8 @@ export type CampaignActivityRow = {
 // ── Helpers ──────────────────────────────────────────────────────────────────
 //
 // The reports V1 RPCs (`get_reports_summary`, `get_orders_by_stop_report`, etc.)
-// from `supabase/migrations/031_reports_v1_rpcs.sql` reference legacy columns
+// (originally from the now-archived supabase migrations; consolidated
+// into `db/migrations/0001_init.sql`) reference legacy columns
 // (`orders.subtotal`, `stops.city/state/date`, `communication_contacts`).
 // The SaaS rebuild has a different `orders` schema (`total_cents`, no
 // `stop_id`/`city`/`state` columns on `stops`) and a different contacts table

src/actions/route-trace/lots.ts

@@ -4,12 +4,13 @@ import { getAdminUser } from "@/lib/admin-permissions";
 import { getActiveBrandId, assertBrandAccess } from "@/lib/brand-scope";
 
 // TODO(migration): the `harvest_lots` / `harvest_lot_events` / `lot_orders`
-// tables from the route-trace feature (defined across
+// tables from the route-trace feature (originally defined in the now-
-// supabase/migrations/143_enable_route_trace.sql and friends) were retired
+// archived supabase migrations; consolidated into
-// from the SaaS rebuild — they don't exist in `db/schema/`. The functions
+// `db/migrations/0001_init.sql`) were retired from the SaaS rebuild —
-// below all return empty results so the public trace page and FSMA reports
+// they don't exist in `db/schema/`. The functions below all return empty
-// 404 gracefully. If route-trace comes back, re-introduce the tables in
+// results so the public trace page and FSMA reports 404 gracefully. If
-// `db/schema/` and replace these stubs with real Drizzle queries.
+// route-trace comes back, re-introduce the tables in `db/schema/` and
+// replace these stubs with real Drizzle queries.
 
 export interface HarvestLot {
   id: string;

src/actions/shipping.ts

@@ -10,10 +10,10 @@ export type UpdateShippingStatusResult =
 // TODO(migration): shipping is dormant in the SaaS rebuild. The legacy
 // `shipments` table (with `tracking_number`, `fedex_shipment_id`, etc.),
 // the `shipping_status` column on `orders`, and the `update_shipping_order`
-// RPC from `supabase/migrations/040_shipping_fulfillment_rpcs.sql` are
+// RPC (originally from the now-archived supabase migrations) are gone.
-// gone. The functions below stub to "not configured" so the admin
+// The functions below stub to "not configured" so the admin shipping
-// shipping tab renders gracefully. Re-introduce shipping in
+// tab renders gracefully. Re-introduce shipping in `db/schema/` when
-// `db/schema/` when the feature is reactivated.
+// the feature is reactivated.
 
 export async function updateShippingStatus(
   _orderId: string,

src/actions/shipping/fedex-labels.ts

@@ -93,8 +93,9 @@ async function loadShippingSettingsForBrand(brandId: string): Promise<ShippingSe
 
 /**
  * Calls the legacy `get_order_items_perishable` SECURITY DEFINER RPC
- * via `pool.query`. The function still lives in the database (see
+ * via `pool.query`. The function still lives in the database
- * supabase/migrations/083_shipping_settings.sql).
+ * (originally from the now-archived supabase migrations; consolidated
+ * into `db/migrations/0001_init.sql`).
  */
 async function isShipmentPerishable(orderId: string): Promise<boolean> {
   try {

src/actions/shipping/fedex-rates.ts

@@ -11,12 +11,12 @@
  *
  * TODO(migration): shipping is dormant in the SaaS rebuild. The
  * legacy `shipping_settings` table (with the FedEx credential columns
- * this file needs) is still present in the database — see
+ * this file needs) is still present in the database — originally from
- * supabase/migrations/083_shipping_settings.sql — but the new
+ * the now-archived supabase migrations, consolidated into
- * `db/schema/` does not declare it. The data reads below hit the
+ * `db/migrations/0001_init.sql` — but the new `db/schema/` does not
- * legacy table directly via `pool.query`. When shipping comes back,
+ * declare it. The data reads below hit the legacy table directly via
- * declare the table in `db/schema/shipping.ts` and switch the reads
+ * `pool.query`. When shipping comes back, declare the table in
- * to Drizzle.
+ * `db/schema/shipping.ts` and switch the reads to Drizzle.
  */
 
 import { getAdminUser } from "@/lib/admin-permissions";

src/actions/shipping/settings.ts

@@ -4,12 +4,12 @@
  * Shipping settings CRUD + FedEx connection test.
  *
  * TODO(migration): shipping is dormant in the SaaS rebuild. The
- * `shipping_settings` table is still part of the legacy schema (see
+ * `shipping_settings` table is still part of the legacy schema
- * supabase/migrations/083_shipping_settings.sql) — the FedEx integration
+ * (originally from the now-archived supabase migrations; consolidated
- * continues to read/write it via raw `pool.query` SQL rather than the
+ * into `db/migrations/0001_init.sql`) — the FedEx integration continues
- * Supabase REST gateway or Drizzle. When shipping is reactivated, move
+ * to read/write it via raw `pool.query` SQL rather than Drizzle. When
- * the table declaration into `db/schema/shipping.ts` and switch the
+ * shipping is reactivated, move the table declaration into
- * reads to typed Drizzle queries.
+ * `db/schema/shipping.ts` and switch the reads to typed Drizzle queries.
  */
 
 import { getAdminUser } from "@/lib/admin-permissions";

src/actions/stops/manage-stop-products.ts

@@ -4,12 +4,13 @@
  * Assign / unassign a product to a stop.
  *
  * TODO(migration): the `assign_product_to_stop` and
- * `unassign_product_from_stop` SECURITY DEFINER RPCs live in
+ * `unassign_product_from_stop` SECURITY DEFINER RPCs (originally from
- * supabase/migrations/030. The RPCs still exist in the database and
+ * the now-archived supabase migrations; consolidated into
- * are called via `pool.query` rather than the Supabase REST gateway.
+ * `db/migrations/0001_init.sql`). The RPCs still exist in the
- * When stops/products are re-platformed on the SaaS rebuild, replace
+ * database and are called via `pool.query`. When stops/products are
- * these with direct inserts/deletes on the new `db/schema/stops.ts`
+ * re-platformed on the SaaS rebuild, replace these with direct
- * `stopProducts` table.
+ * inserts/deletes on the new `db/schema/stops.ts` `stopProducts`
+ * table.
  */
 
 import { getAdminUser } from "@/lib/admin-permissions";

src/actions/tax.ts

@@ -152,12 +152,12 @@ async function getBrandTaxSettings(brandId: string): Promise<BrandTaxSettings |
 //
 // TODO(migration): the tax dashboard reads from the legacy `orders`
 // table via the `get_tax_summary` and `get_taxable_orders` SECURITY
-// DEFINER RPCs (supabase/migrations/095). Both the table and the RPCs
+// DEFINER RPCs (originally from the now-archived supabase migrations;
-// still exist; we call the RPCs through `pool.query` rather than the
+// consolidated into `db/migrations/0001_init.sql`). Both the table and
-// Supabase REST gateway. When the SaaS rebuild's orders table grows a
+// the RPCs still exist; we call the RPCs through `pool.query`. When the
-// `tax_amount` column or the tax dashboard is rebuilt against the new
+// SaaS rebuild's orders table grows a `tax_amount` column or the tax
-// schema, these helpers should be rewritten against the Drizzle
+// dashboard is rebuilt against the new schema, these helpers should be
-// `orders` table directly.
+// rewritten against the Drizzle `orders` table directly.
 
 export type TaxByStateRow = {
   state: string;

src/app/admin/page.tsx

@@ -32,7 +32,7 @@ export default async function AdminPage() {
   // so a transient DB/network failure can't crash the whole admin page.
   let dashboardBrandId: string | null = adminUser ? await getActiveBrandId(adminUser) : null;
   if (!dashboardBrandId && adminUser?.role === "platform_admin") {
-    // Direct pg query (the supabase shim returns empty results).
+    // Direct pg query (the legacy query-builder shim returned empty results).
     // This ensures a platform_admin sees real dashboard stats even on first login
     // before they have chosen an active brand.
     try {

src/app/api/wholesale/checkout/route.ts

@@ -4,7 +4,8 @@
  * TODO(migration): wholesale_orders is part of the legacy schema and
  * is read/written via raw `pool.query` SQL. The `get_wholesale_settings`
  * and `get_payment_settings` SECURITY DEFINER RPCs still live in the
- * database (see supabase/migrations/046 and 045) and are also called
+ * database (originally from the now-archived supabase migrations;
+ * consolidated into `db/migrations/0001_init.sql`) and are also called
  * via `pool.query`. When wholesale is reactivated, declare the tables
  * in `db/schema/wholesale.ts` and switch the reads to typed Drizzle.
  */

src/app/api/wholesale/price-sheet/route.ts

@@ -5,10 +5,10 @@
  * `enqueue_wholesale_notification` SECURITY DEFINER RPC live in the
  * legacy schema. Reads are converted to `pool.query`; the
  * `enqueue_wholesale_notification` RPC is still in the database
- * (supabase/migrations/054) and is called via `pool.query` rather
+ * (originally from the now-archived supabase migrations; consolidated
- * than the Supabase REST gateway. When wholesale is reactivated,
+ * into `db/migrations/0001_init.sql`) and is called via `pool.query`.
- * move the tables into `db/schema/wholesale.ts` and switch reads to
+ * When wholesale is reactivated, move the tables into
- * typed Drizzle.
+ * `db/schema/wholesale.ts` and switch reads to typed Drizzle.
  */
 
 import { NextRequest, NextResponse } from "next/server";