Custom query serializer for createRouterControls / createRouter

### Problem

Query serialization is hardcoded to `query-string` in `create-router-controls.ts` (parse on `locationUpdated`, stringify in `navigateFx`). atomic-router lets users inject a `ParamsSerializer` (`{ read, write }`) — needed for array formats (`a[]=1` vs `a=1,2`), typed encodings, or matching an existing backend contract. Without an injection point this is a feature-parity gap with no workaround short of a custom adapter that rewrites `location.search`.

### Proposed solution

```ts
interface QuerySerializer {
read(search: string): Query; // 'a=1&b=2' -> Query
write(query: Query): string; // Query -> 'a=1&b=2' (no leading '?', controls add it)
}

createRouterControls({ serialize?: QuerySerializer });
createRouter({ routes, serialize?: QuerySerializer }); // forwarded to its own controls
```

Default is the current `query-string` behavior, exported as `defaultQuerySerializer`. Passing both `controls` and `serialize` to `createRouter` is a dev-mode error — the serializer belongs to the controls instance. The `{ read, write }` shape matches atomic-router's `ParamsSerializer` verbatim, so migration is copy-paste.

### Alternatives considered

Wrapping the history adapter to rewrite `search` — works but duplicates parsing and breaks `$query` consistency.

### Package

`@effector/router` (core)

Start in create-router-controls.ts, tracing the query-string parsing on locationUpdated and stringifying in navigateFx. Then follow createRouter's controls setup to understand where a serializer can be forwarded and how the controls/serialize conflict is handled. Done means injected read/write behavior works for custom query formats while the default query-string behavior remains unchanged.

Written by the indexing model from the issue text.