fix(billing): post-#705 follow-ups — backfill + cleanup

editor/app/(site)/organizations/[organization_name]/settings/billing/upgrade/_view.tsx

@@ -313,11 +313,6 @@ export default function UpgradeView({
           );
         })}
       </div>
-
-      <p className="text-xs text-muted-foreground mt-4">
-        Test mode: use card <code>4242 4242 4242 4242</code>. After payment,
-        you&apos;ll be redirected back here. Provisioning takes a few seconds.
-      </p>
     </>
   );
 

supabase/migrations/20260507000000_grida_billing_backfill_provision.sql

@@ -0,0 +1,28 @@
+-- Backfill billing provisioning for orgs that pre-date 20260506132900.
+--
+-- The base migration adds an `AFTER INSERT` trigger that calls
+-- `fn_provision_account` to create the `grida_billing.account` and free
+-- `grida_billing.subscription` rows. The trigger only fires on NEW orgs;
+-- pre-existing orgs were left without their billing rows. This blocks
+-- their first checkout because `fn_attach_stripe_customer` (correctly)
+-- refuses to attach a Stripe customer to a non-provisioned account.
+--
+-- Production hit this on org 255: "billing account not provisioned for
+-- organization 255".
+--
+-- Iterate every existing org and call `fn_provision_account` (idempotent:
+-- INSERT … ON CONFLICT DO NOTHING). The guard in fn_attach_stripe_customer
+-- stays loud — once the data is right, that RAISE is the correct behavior
+-- for any future anomaly (deleted row, bypassed trigger, partial restore).
+
+DO $$
+DECLARE
+  rec RECORD;
+  n   integer := 0;
+BEGIN
+  FOR rec IN SELECT id FROM public.organization LOOP
+    PERFORM grida_billing.fn_provision_account(rec.id);
+    n := n + 1;
+  END LOOP;
+  RAISE NOTICE 'grida_billing backfill: provisioned % organizations', n;
+END $$;