PDF "open in external window" gets no theme: `resolve-styles!` links only `style.css`

Nobody has claimed this yet.

## What happens

Opening a PDF and clicking **Open in external window** gives a window that is always stock
Logseq: no theme, and no `custom.css`. The same PDF viewer in the main window is themed
normally.

This affects every theme, not one in particular — nothing a theme or a graph's
`custom.css` can do reaches that window.

## Why

The external window is not a route. It is built by hand in
[`src/main/frontend/extensions/pdf/windows.cljs`](https://github.com/logseq/og/blob/version/file/src/main/frontend/extensions/pdf/windows.cljs)
(`setup-win!`), and its stylesheets come from `resolve-styles!`:

```clojure
(defn resolve-styles!
[^js doc]
(doseq [r ["./css/style.css"]] ; <- the app's own sheet, and nothing else
(let [^js link (js/document.createElement "link")]
(set! (.-rel link) "stylesheet")
(set! (.-href link) r)
(.appendChild (.-head doc) link))))
```

Registered themes and `custom.css` are injected into the **main** document, which this
window is not part of, so they never appear in it.

Everything else about the window is already set up for theming — `setup-win!` copies the
theme mode onto the new document and marks it:

```clojure
(set! (.-dataset doc-el) -theme (str theme-mode)) ; data-theme is set
(resolve-classes! doc) ; adds .is-system-window
```

So a theme's own selectors (`html[data-theme] …`) would match immediately. The stylesheet
is simply absent.

## Suggested fix

Have `resolve-styles!` also carry whatever the main document is using:

- the active theme's stylesheet (the registered theme's URL, as the main document links
it), and
- the graph's `custom.css`.

A plugin *can* work around this today by patching `window.open` on the host renderer and
appending the sheets to the new document — but that is host monkey-patching from what is
often just a theme, and it is the kind of unofficial host access the plugin SDK warns is
unsupported on the Marketplace. It also has an ordering trap worth noting for the fix
itself: `setup-win!` appends `style.css` synchronously after `open()` returns, so a sheet
added any earlier loses every specificity tie against it. Whatever links the theme should
do so **after** `style.css`, exactly as the main document does.

## Steps to reproduce

1. Enable any theme (a marketplace theme, or a `custom.css` with something obvious like
`body { background: red }`).
2. Open a PDF asset in the PDF viewer — it is themed.
3. Click **Open in external window**.
4. The new window is unthemed.

## Environment

- Logseq OG, `version/file` @ `6e7afa8eb` (code verified against that tip)
- Linux / Wayland (GNOME), but nothing here looks platform-specific
- Reported from writing a GNOME/Adwaita theme, where the external PDF window is the only
surface the theme cannot reach

Start in src/main/frontend/extensions/pdf/windows.cljs, reading setup-win! and resolve-styles! to trace how the external document receives data-theme, style.css, and classes. Compare the main document's linked theme stylesheet and custom.css handling, then confirm the external PDF window receives those sheets after style.css and is themed consistently.

Written by the indexing model from the issue text.