DB import crashes with "db-worker has not been initialized" / null pointer in worker reconnection path during large markdown import

Nobody has claimed this yet.

**Update:** the property-type issues I originally suspected (Zotero metadata, duplicate aliases) turned out to be real but separate bugs — fixed, but didn't resolve the crash. Rewrote the description below with a new theory based on two reproducible runs: the crash seems to follow shortly after a db-worker-runtime-recovered event rather than being tied to any specific page's content.

**Environment:**
- Logseq DB version (desktop, macOS)
- Import path: importing an existing markdown graph (OG graph, ~2964 pages)

**Summary:**
Importing a large markdown graph into a new DB graph completes its file-count progress bar (e.g. "2964/2964") but the app remains stuck on "Loading," and a burst of popup errors appears:
```
Import failed on "" with error: db-worker has not been initialized
```
DevTools reveals the underlying sequence: the local backend/db-worker process becomes unreachable (`net::ERR_CONNECTION_REFUSED`, repeated), Logseq detects this and logs `:db-worker-runtime-recovering`, then shortly after `:db-worker-runtime-recovered`. Every page whose write was in flight during the outage fails with the generic "not initialized" message — these are consistent and expected given the outage window, and land as contiguous runs of alphabetically/chronologically adjacent files.

**Separate, more serious issue — likely the actual blocker:**
Some time *after* a `:db-worker-runtime-recovered` event (not during the outage itself), a second failure occurs:
```
[frontend.handler] {:exception #error {:message "Promise error", :cause #error {:message "Cannot read properties of null (reading 'toLowerCase')", :data {:status 500, ...}}}}
```
This one is not accompanied by any `:import-error` log entry naming a specific page — it appears to come from a different code path than the per-file import error handling. Two independent runs on the same source graph show:

| Run | Recovery time | Crash time | Delay | Last logged page before crash |
|---|---|---|---|---|
| 1 | 22:57:10.513 | 22:57:18.384 | ~8s | `pages/Some_file.md` |
| 2 | 00:28:25.848 | 00:29:26.880 | ~61s | `pages/Yet_another_file.md` |

The crash occurs at a **different page** and after a **different delay** each run, always following a recovery event by some variable amount of time. This pattern — rather than a fixed page failing consistently — suggests the fault may not be in the imported content at all, but in the **worker reconnection/retry logic itself**: possibly a `null` value being read from a resumed state object, retry queue entry, or response header during/after reconnection, on which `.toLowerCase()` is then called.

**Ruled out so far:**
- Malformed Zotero-imported bibliography properties (`issue`, `edition`, `num-pages`, `rights`, `url` not matching their inferred type) — found and fixed several real instances of this on `@`-prefixed reference pages; did not resolve the crash.
- Duplicate `:block/alias` values claimed by more than one page (a separate, legitimately-caught validation error, distinct from the crash above) — found and fixed two instances; did not resolve the crash.
- A full-graph scan for the same property-type mismatches (`date`, `issue`, `edition`, `num-pages`, `rights`, `url`) across all pages, not just Zotero ones — found nothing.

**Steps to reproduce:**
1. Have a large (~3000 page) OG markdown graph.
2. In DB-version Logseq, import the existing graph.
3. Progress bar completes, but "Loading" persists; error toasts appear for a batch of pages.
4. Open DevTools (Cmd+Option+I) during import; observe `ERR_CONNECTION_REFUSED` → `:db-worker-runtime-recovering` → `:db-worker-runtime-recovered` → (some delay) → `Cannot read properties of null (reading 'toLowerCase')`.

**Additional UX issue:** the error toast stack is not scrollable and discards all but the last handful of messages on a large import, making it impossible to see the complete failure list from the UI alone.

**Suggested fixes:**
- Investigate the worker reconnection/retry path for a `null`-safety gap around wherever `.toLowerCase()` is called shortly after `:db-worker-runtime-recovered` fires.
- Don't let a single coercion/reconnection failure abort the whole import; skip/retry the affected item and continue.
- Make the import error list scrollable/exportable.

Start by reproducing the large markdown import and inspecting DevTools logs around ERR_CONNECTION_REFUSED, db-worker-runtime-recovering, and db-worker-runtime-recovered. Trace the worker reconnection or retry path to the null value used with .toLowerCase(); done means the import survives recovery without aborting and its failures remain visible in the error list.

Written by the indexing model from the issue text.