fix: honor the Antora prompt setting and keep the content catalog alive

[ggrossetie]

• asciidoc.antora.showEnableAntoraPrompt was declared and documented but never read, so it had no effect. It is now honoured and the prompt becomes 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.
• The very first document never triggered the prompt: the document-open listener is registered during activation, but the 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. The already-open documents are now scanned at activation.
• "Enable Antora support in this workspace" now registers the gated features immediately (the { attributes completion) instead of after a window reload; registration is idempotent (prompt + command cannot stack duplicate providers) and "Disable Antora support in this workspace" tears them down symmetrically.
• A single collision no longer kills the whole catalog. Two antora.yml files declaring the same component name and version (a clone and a copy of the same component, or overlapping folders in a multi-root workspace) made the classifier throw Duplicate version detected, and an unquoted version: 2.0 (a YAML number) made it throw as well; either failure silently disabled every Antora feature (resource id completion, go to definition, preview resolution) for all components. Duplicated antora.yml URIs are now deduplicated, entries sharing a component name and version are merged before classification — first descriptor wins, files deduplicated by their path within the component, mirroring Antora's own aggregator — and a non-string version is coerced to a string.
• Read the antora.yml bytes explicitly as UTF-8 when building the catalog: yaml.load was handed the raw Uint8Array (the pre-existing TS error in buildAntoraConfigs) and only worked because the desktop host returns a Buffer whose toString decodes UTF-8; on any other host the implicit String() coercion produces a comma-separated byte string.
• Clarify the "remote content sources" limitation on the Antora page: it refers to content sources an Antora playbook would fetch from remote git repositories, not to remote development setups such as VS Code Remote - SSH (there the extension runs on the remote host, so workspace files count as local). Also document that the prompt is opt-in through asciidoc.antora.showEnableAntoraPrompt.