fix(datagrid): restore applied filters when reopening a table (#1347)

[datlechin]

What

Reopening a table now restores the filter you last applied to it, matching TablePlus. This covers closing and reopening a table within a session, and reopening after quitting and relaunching the app.

Addresses #1347 (scope settled in the issue: persist the filter on reopen, rather than adding an always-visible empty filter bar).

Root cause

Filters were already saved on apply, but restoration was broken in three stacked places:

1. Restoration was gated on the "Restore Last Filter" panel-state setting, which defaulted to "Always Hide", so nothing was ever restored out of the box.
2. Opening a table into a window that already had tabs ran a path that restored hidden columns but not filters.
3. App restart never restored filters.

A latent bug compounded this: the saved-filter file was keyed by the raw table name only, so the same table name collided across connections and schemas. Invisible while restoration was off; turning restoration on by default would have shown one connection's filter in another.

Changes

• FilterSettingsStorage: key per (connection + database + schema + table); default panel state is now "Restore Last Filter"; a one-time migration upgrades users still on "Always Hide" and removes the old single-key files.
• FilterCoordinator: restore unless the user chose "Always Hide", and show the filter bar populated when a filter is restored. The restore decision is a pure function so it can be unit tested.
• Restoration is wired into every table-open path (sidebar reopen, new native tab, app restart) and bakes the filter into the query before it runs. A filter carried by "open related rows" (foreign-key navigation) keeps precedence.

"Always Hide" still means do not restore, matching TablePlus.

Tests

• FilterSettingsStorageTests: save/load round-trip, on-disk persistence across a fresh storage instance, isolation across connections, databases, and schemas, empty-clears, the new default, and the migration.
• FilterRestoreTests: the restore decision for each panel state.

Scope and known limitations

• Cross-database reopen is not covered. When a reopened tab's database differs from the connection's currently active database, opening it calls switchDatabase, which clears filter state and rebuilds the tab list as a global operation. This pre-dates this change and affects hidden-column restoration too. Preserving per-table state across a database switch is a separate refactor of cross-database tab opening, not part of this fix. For normal sidebar reopens the tab's database matches the active database, so this path is not hit.
• No schema validation on restore. A reopened tab's columns are not loaded until after restoration runs, so a synchronous "drop clauses for missing columns" check would be a no-op in the cases that matter. Doing it properly needs async schema loading and is better as a separate change. A stale filter currently surfaces a normal DB error with the editable filter visible, so it stays recoverable.