[FEATURE]: Add storeNames to ImportOptions for selective restore

### Feature and its Use Cases

`ExportOptions` supports `storeNames?: string[]`, so callers can export a subset of stores.
`ImportOptions` has no equivalent, exposing only `dbName`, `backupData` and `strategy`.

The result is an asymmetry in the public API: a backup can be produced selectively but not consumed
selectively. Callers who want a partial restore have to mutate `backupData.stores` themselves before
handing it to `importDB`, which means reaching into the envelope structure the library otherwise owns.

**What the feature is:** add `storeNames?: string[]` to `ImportOptions`. When present, only the named
stores are restored. When omitted, behaviour is unchanged, so this is backwards compatible.

**Who benefits**

- Any app whose database mixes durable user data with derived caches. Restoring a stale cache is
usually worse than refetching it, so "restore some stores" is the common case rather than an edge case.
- It closes the export/import symmetry gap, which also makes the two option types easier to document
together.
- Fate Protocol has 9 stores in `FatePoolsDB`, of which 3 hold user portfolio data
(`portfolioPositions`, `portfolioTransactions`, `portfolioCache`). The other 6 are RPC caches that
should be refetched from chain rather than restored from a file that may be days old.

### Additional Context

The current workaround is to filter `backupData.stores` before calling `importDB`, which works but
couples the caller to the envelope shape. A `backupVersion` 2 that changed that shape would break
such callers silently, with no type error.

Related: pairs naturally with an `onBeforeImport` hook, filed separately as #68.

### Code of Conduct

- [x] I have joined the [Discord server](https://discord.gg/hjUhu33uAn) and will post updates there
- [x] I have searched existing issues to avoid duplicates