`IQueryModifier.toSql` signature is narrower than the class impl in pg-meta

## Summary `packages/pg-meta/src/query/QueryModifier.ts` exports an interface `IQueryModifier` whose `toSql` signature is narrower than both the implementing class `QueryModifier` and the actual internal call sites. `QueryModifier.ts:12-15` (interface): ```ts export interface IQueryModifier { range: (from: number, to: number) => QueryModifier toSql: () => SafeSqlFragment } ``` `QueryModifier.ts:44-46` (class): ```ts toSql( options: { isCTE: boolean; isFinal: boolean } = { isCTE: false, isFinal: true } ): SafeSqlFragment { ``` The class accepts an optional `options` argument, but the interface declares `toSql` as taking no arguments at all. This isn't just theoretical — real call sites already pass that argument: - `packages/pg-meta/src/query/QueryFilter.ts:68` — `this._getQueryModifier().toSql(options)` - `packages/pg-meta/src/query/table-row-query.ts:184` — `.toSql({ isCTE: false, isFinal: false })` - `packages/pg-meta/src/query/table-row-query.ts:259` — `.toSql({ isCTE: true, isFinal: true })` These type-check today only because the callers hold a reference typed as the concrete `QueryModifier` class (inferred, e.g. from `new QueryModifier(...)` or `_getQueryModifier()`'s inferred return type), not the `IQueryModifier` interface. Any consumer that types the receiver as `IQueryModifier` — e.g. `const m: IQueryModifier = ...` — would be blocked from passing `options` even though every real implementation and caller needs to. This is the same class of bug as #47589 (`IQueryFilter.filter` narrower than its class/type), in a sibling file of the same package. ## Suggested resolution Widen `IQueryModifier.toSql` to match the class: ```ts toSql: (options?: { isCTE: boolean; isFinal: boolean }) => SafeSqlFragment ``` Widening a parameter type (here, adding an optional param) is non-breaking for existing consumers — every call that satisfied the old signature still satisfies the new one. ## Environment - Repo: supabase/supabase @ master