fix(preview): allow interactive SVG objects through CSP frame-src

Asciidoctor renders image::foo.svg[opts=interactive] as
<object type="image/svg+xml" data="..."> rather than <img>. The preview's
Content-Security-Policy allow-listed object-src for it but not frame-src —
Chromium (the webview's engine) gates an <object> that navigates to an
SVG/HTML document, opening a nested browsing context, by frame-src (falling
back through child-src to default-src 'none' when unset), not object-src
alone, so the SVG silently failed to load with nothing shown. frame-src now
mirrors object-src's allow-list, including the "allow insecure content"/
"allow insecure local content" exceptions.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

Author: ggrossetie

CHANGELOG.md

@@ -11,6 +11,7 @@
 
 ### Bug fixes
 
+* Render `image::foo.svg[opts=interactive]` in the preview. Asciidoctor renders an SVG image with `opts=interactive` as `<object type="image/svg+xml" data="...">` rather than `<img>`, and the preview's Content Security Policy allow-listed `object-src` for it but not `frame-src` — Chromium (the webview's engine) gates an `<object>` that navigates to an SVG/HTML document, i.e. one that opens a nested browsing context, by `frame-src` (falling back through `child-src` to `default-src 'none'` when unset), not `object-src` alone, so the SVG silently failed to load with no content shown. `frame-src` now mirrors `object-src`'s allow-list, including the `asciidoc.preview.security` "allow insecure content"/"allow insecure local content" exceptions
 * Make the `asciidoc.antora.showEnableAntoraPrompt` setting effective, and stop missing the "enable Antora support?" prompt for the document that activated the extension. The setting was declared (default `false`) and documented but never read, so the prompt always showed as long as no decision had been recorded for the workspace. It is now honoured: the prompt is opt-in — the check runs before anything else, so with the prompt disabled (the default) opening documents no longer triggers the `antora.yml` file system lookup at all — and the setting can be flipped mid-session without reloading the window. Additionally, the prompt only listened to document-open events registered *during* activation, while the very document whose opening activates the extension fires that event *before* the listener exists — so a session where a single Antora page was opened never showed the prompt (when enabled); the already-open documents are now scanned at activation. Finally, the "Enable Antora support in this workspace" command now registers the Antora-gated features (the `{` attributes completion) immediately — previously they only appeared after the window was reloaded — registration is idempotent so enabling twice (prompt then command) does not stack duplicate providers, and "Disable Antora support in this workspace" now tears them down symmetrically
 * Keep the Antora content catalog alive when the workspace aggregates the same component version twice or declares a non-string version. Two `antora.yml` files with the same `name` and `version` — e.g. a clone and a copy of the same component, or overlapping folders in a multi-root workspace — made the content classifier throw `Duplicate version detected`, and an unquoted `version: 2.0` (parsed by YAML as a number) made it throw as well; either failure took the *whole* catalog down, so every Antora feature (resource id completion, go to definition, preview resolution) silently stopped working for *all* components, with only an "Unable to get Antora context" entry in the Asciidoctor output channel as a clue. The same `antora.yml` surfaced several times by overlapping workspace folders is now deduplicated, entries sharing a component name and version are merged before classification (first descriptor wins, files concatenated and deduplicated by their path within the component, so two copies of the same tree collapse to the first — mirroring Antora's own aggregator, which legitimately assembles one component version from several content sources), and a non-string `version` is coerced to a string instead of crashing the classifier
 * Make Antora resolution failures diagnosable from the "Asciidoctor" output channel instead of silent. Users troubleshooting a workspace where xref/attribute completion stayed empty had no way to tell *why* a document wasn't resolving, short of reading the source: which `antora.yml` files were found, which ones got dropped (duplicate path, missing `name`/`version`, symlinked parent directory), which component/version pairs got merged and from where, and — the most common dead end — a document that has a valid `antora.yml` but does not match any file in the content catalog. All of these now log to the channel (`info`/`warn` for conditions worth a user's attention, `debug`/`trace` for the rest, visible after raising the channel's log level via "Developer: Set Log Level…"), each message naming the file path(s) involved