`IQueryFilter.filter` signature is narrower than the class impl and `Filter` type in pg-meta

## Summary `packages/pg-meta/src/query/QueryFilter.ts` exports an interface `IQueryFilter` whose `filter` signature is narrower than both the implementing class `QueryFilter` and the underlying `Filter` type in `packages/pg-meta/src/query/types.ts`. The three definitions are out of sync. ## Evidence `QueryFilter.ts:5` (interface): ```ts filter: (column: string, operator: FilterOperator, value: string) => IQueryFilter ``` `QueryFilter.ts:20` (class): ```ts filter(column: string | string[], operator: FilterOperator, value: any) { ... } ``` `types.ts:30-34`: ```ts export interface Filter { column: string | Array<string> operator: FilterOperator value: any } ``` The existing test suite passes shapes that the interface signature technically rejects: - `packages/pg-meta/test/query/advanced-query.test.ts:547` — `.filter('id', 'in', [1, 2, 3])` (array value). - `packages/pg-meta/test/query/query.test.ts:418` — `Filter[] = [{ column: 'id', operator: 'in', value: [1, 2, 3] }]`. These type-check today only because callers get the *class* type via inference from `new QueryFilter(...)`. Any consumer that types the receiver as `IQueryFilter` — e.g. `const q: IQueryFilter = queryAction.select()` — is blocked from passing an array column or a non-string value even though the class accepts them fine. It's a latent trap, not an active runtime bug. ## Suggested resolution Widen `IQueryFilter.filter` to match the class and the `Filter` type: ```ts filter: (column: string | string[], operator: FilterOperator, value: any) => IQueryFilter ``` Widening parameter types is contravariantly safe — every call that satisfied the old signature still satisfies the new one, so this is non-breaking for external consumers of the package. PR: #47588 (one-line change). ## Environment - Repo: supabase/supabase @ `61078d26` (master, 2026-07-03)