Declarative schema migration generation broken for JOIN views after CLI update

Start by reproducing the behavior with Supabase CLI 2.34.3 using a declarative schema in supabase/schemas/*.sql and a view containing a JOIN. Trace the supabase db diff path and its SQL deparser, comparing the generated DROP VIEW / CREATE VIEW statements across repeated runs. Done means an unchanged JOIN view produces no migration output after the migration is applied.

Describe the bug
After upgrading to the latest Supabase CLI (2.34.3), supabase db diff in declarative schema mode is endlessly re-generating migrations for views that contain JOINs, even if no actual changes have been made to the view SQL.

Before the CLI update, these views were stable. Now, after every db diff, the same DROP VIEW / CREATE VIEW statements are produced, leading to an infinite migration loop.

To Reproduce
Steps to reproduce the behavior:

1. Upgrade to the latest Supabase CLI
2. Have a project using declarative schema (supabase/schemas/*.sql).
3. Include a view with a join, for example:

create or replace view public.timeslips_view as
select
  o.name,
  tr.timeslips_requested,
  tr.created_at,
  tr.download_link,
  tr.modified_at
from public.timeslips_requests tr
left join public.organisations o on tr.organisation_id = o.id
order by tr.created_at desc;

4. Create migration with supabase stop && supabase db diff -f migration_name
5. Re-run the diff

Expected behavior
If no changes have been made to the database or declarative schema, supabase db diff should produce no output.

Actual behavior
The CLI repeatedly outputs the same DROP VIEW / CREATE VIEW statements for affected views. This repeats indefinitely after each run, even immediately after applying the migration.

Notes / Observations
• The issue appears specific to views containing JOINs — views without joins are unaffected.
• Happens whether or not schema qualification (public.) is used in the FROM clause.
• Removing WITH (security_invoker...) and ALTER ... OWNER from the declarative schema does not resolve it.
• Likely linked to a change in the CLI’s SQL deparser in the most recent release.