fix(reset): ensure pgmq extension is fully rebuilt during remote resets

[7ttp]

ERROR: relation "pgmq.q_<queue>_msg_id_seq" does not exist

Related issue: #4492

---

🐛 Root cause

Preview-branch resets can leave the pgmq extension in a partial / inconsistent state, where some extension-managed objects (tables or sequences) are missing.
When migrations later execute pgmq.create(...), the extension expects these objects to exist and fails with missing-relation errors.

---

✅ What this change does

During remote resets only, this PR:

• Checks whether the pgmq extension exists
• If present, runs:
  DROP EXTENSION IF EXISTS pgmq CASCADE
• Recreates it with:
  CREATE EXTENSION IF NOT EXISTS pgmq
• Uses a short bounded retry to tolerate transient lock or catalog-contention issues
• Then continues with the standard down.ResetAll(...) migration flow

This ensures the PGMQ extension is always in a known-good, consistent state before migrations run, eliminating missing-sequence errors.

---

📌 Notes

• Change is scoped only to the remote / preview-branch reset path
• Local development resets are unaffected
• If the remote Postgres instance disallows extension creation or removal, the reset will fail with a clear error — this is expected and indicates a platform-side configuration issue

---

🔧 What kind of change does this PR introduce?

Bug fix

---

🚨 Current behavior

Preview-branch resets may leave the PGMQ extension in a partial state, causing migrations such as:

SELECT pgmq.create('my_queue');
SELECT pgmq.create('my_queue_dlq');

to fail with missing-relation errors.

More details: #4492

---

🎉 New behavior

Preview-branch resets now consistently rebuild the PGMQ extension, ensuring all pgmq.create(...) migrations run successfully without errors.

---

📎 Additional context

• Issue occurs only on preview-branch resets (first builds and new commits work normally)
• Verified locally using a disposable Postgres container

[coveralls]

Pull Request Test Coverage Report for Build 19625585658

Details

• 1 of 24 (4.17%) changed or added relevant lines in 1 file are covered.
• 6 unchanged lines in 2 files lost coverage.
• Overall coverage decreased (-0.1%) to 54.979%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
internal/db/reset/reset.go	1	24	4.17%

Files with Coverage Reduction	New Missed Lines	%
internal/db/reset/reset.go	1	63.85%
internal/gen/keys/keys.go	5	12.9%

Totals
Change from base Build 19620063801:	-0.1%
Covered Lines:	6531
Relevant Lines:	11879

---

💛 - Coveralls

[sweatybridge]

You should enable the pgmq extension from your migration files. For eg. supabase/migrations/<timestamp>_name.sql

create extension if not exists pgmq;

select pgmq.create('my_queue');

[7ttp]

thanks @sweatybridge for the heads-up! I haven’t added the migration yet but I’ll include the pgmq extension setup:

CREATE EXTENSION IF NOT EXISTS pgmq;
SELECT pgmq.create('my_queue');

I’ll push the update shortly.

[sweatybridge]

Cool, all extension related setup should be enabled through user created migration files. I will probably close this PR if you can confirm that the above comment works.

[ToJen]

@sweatybridge unfortunately adding create extension in the migrations is not enough. it will still fail after a reset. @7ttp what was the outcome for you?

[7ttp]

i tested it again just to be sure, adding create extension if not exists pgmq in the migrations wasn’t enough on my side either. after a remote/preview reset the extension objects were still in a partial state, so the next pgmq.create(...) call failed with the same missing-relation error. @ToJen @sweatybridge

[ToJen]

@sweatybridge

[7ttp]

@ToJen @sweatybridge I’m working on the fixes now. I’ll clean up the gofmt formatting, add the missing migration so the recommendation is covered, and update the PR to align with the feedback. I’ll push the updates shortly.

[7ttp]

@sweatybridge Could you take a look at this when you have a moment?

[sweatybridge]

I don't think it's the CLI's responsibility to customise user's migrations for any specific extensions. So I will go ahead and close this PR.

I will follow up on the original issue to resolve any errors you are facing #4492