feat: replace LevelDB with DuckDB as persistence backend

[halgari]

What this PR does

Vortex is gradually moving business logic out of the renderer process (React/Redux) and into the main process. This PR replaces the LevelDB persistence backend with DuckDB (via the `level_pivot` extension), and adds the infrastructure for main-process code to write state and sync it back to the renderer.

How it works

Persistence backend

DuckDB attaches a LevelDB file as a typed relational database via the `level_pivot` extension. State is stored as `path -> JSON value` pairs, so the renderer's Redux store and hydration flow are unchanged. A single `DuckDBSingleton` owns the DuckDB instance and connection pool; each `LevelPersist` database attaches to it under a unique alias so all hives share one engine.

Bidirectional sync

State previously only flowed renderer -> Redux -> `persist:diff` IPC -> main -> LevelDB. Main-process code can now also initiate writes:

1. Call `pushStateToRenderer(hive, operations)` with a list of diff operations
2. Main writes them to DuckDB and waits for the write to flush
3. Main sends a `persist:push` IPC message to all renderer windows
4. Renderer applies the operations via a `__persist_push` Redux action
5. `persistDiffMiddleware` skips `__persist_push` actions to avoid a feedback loop

SQL query files and the parser

Named SQL queries live in `src/queries/` as plain `.sql` files annotated with a comment-based DSL:

-- @type select
-- @name recently_managed_games
-- @description Games the user has managed, sorted by last activation date
-- @param profile_id VARCHAR
SELECT game_id, last_activated FROM ...

The `@type` tag at the top of each file controls how the query is handled. `setup` queries create pivot tables at startup; `view` queries create SQL views; `select` queries are the named, parameterised queries called by name at runtime.

`queryParser.ts` scans the `src/queries/` tree at runtime, parses each file extracting annotations and SQL body, validates name uniqueness across all files, and returns a list of `ParsedQuery` objects.

Code generation

`scripts/generate-query-types.ts` is a build-time script that:

1. Spins up a temporary DuckDB instance and attaches an empty LevelDB for schema-only work
2. Runs all `setup` queries, then `DESCRIBE`s them to read column types
3. Runs all `view` queries, then `PREPARE`s each `select` query to read result column metadata
4. Maps DuckDB column types to TypeScript types (`VARCHAR -> string`, `INTEGER -> number`, etc.)
5. Writes `src/main/store/generated/queryTypes.ts` with typed `Params` and `Row` interfaces for every query, a `Models` interface with typed `Table`/`View` accessors, and a `createModels(db)` factory

SQL schema changes propagate to TypeScript automatically with a single script run.

Live query updates

After each write transaction commits, `LevelPersist` reads `level_pivot_dirty_tables()` to find which tables were modified. Those table names are forwarded to `QueryInvalidator`, which debounces rapid writes (~16 ms) and batches them before acting.

`QueryRegistry` maintains a reverse index built at startup by calling `getTableNames(sql)` on each registered query, producing a map of `tableName -> Set`. `QueryInvalidator` uses this index to resolve dirty tables into affected query names.

`QueryWatcher` holds a set of active subscriptions. When `QueryInvalidator` flushes, it calls `QueryWatcher.onQueriesInvalidated(affectedQueries)`. For each matching subscription the watcher re-executes the query, JSON-compares the result to the previous snapshot, and fires the callback only if something changed, delivering `{ previous, current }` diffs to subscribers.

This is all main-process only. The renderer continues using Redux; live query results feed back to Redux via `pushStateToRenderer` when main-process code decides to act on them.

Why DuckDB

As we move code to the main thread, we want main-process logic to query and write application state using real SQL. DuckDB gives us joins, aggregations, window functions, and typed schemas on top of the same LevelDB files already on disk.

[insomnious]

Closes APP-67

[github-actions]

This PR has conflicts. You need to rebase the PR before it can be merged.

[github-actions]

This PR doesn't have conflicts anymore. It can be merged after all status checks have passed and it has been reviewed.

[github-actions]

This PR has conflicts. You need to rebase the PR before it can be merged.

[github-actions]

This PR doesn't have conflicts anymore. It can be merged after all status checks have passed and it has been reviewed.

[erri120]

I pushed some small fixes to keep the PR feedback loop small on this. Only issue is the generate-query-types script which I'm not sure when or how we want to use it and also it has import failures.

[github-actions]

This PR has conflicts. You need to rebase the PR before it can be merged.

[github-actions]

This PR doesn't have conflicts anymore. It can be merged after all status checks have passed and it has been reviewed.

[github-actions]

This PR has conflicts. You need to rebase the PR before it can be merged.

[Aragas]

Looks really cool!

[github-actions]

This PR doesn't have conflicts anymore. It can be merged after all status checks have passed and it has been reviewed.

[erri120]

I'm getting this error when launching Vortex:

Failed to store application state: Binder Error: The specified columns as conflict target are not referenced by UNIQUE/PRIMARY KEY CONSTRAINT or INDEX

Stack shows ReduxPersistorIPC.ts:253:11.