Remove runtime Gondolin dependency once asset/version APIs are available

[vmg-dev]

Summary

docker2vm should stop depending on @earendil-works/gondolin at runtime.

We currently keep this dependency as a temporary fallback for guest-asset resolution, but it creates coupling to Gondolin internals and version behavior that we want to avoid.

Why remove this dependency

• Keeps docker2vm independent from Gondolin implementation details.
• Avoids importing Gondolin internals just to fetch guest assets.
• Reduces breakage risk when Gondolin changes internal APIs/behavior.
• Better separation of concerns: docker2vm consumes assets, it should not need Gondolin runtime code to produce them.

Desired direction

Use external/CLI-driven asset flow instead of package dependency:

1. User provides assets explicitly (e.g. GONDOLIN_GUEST_DIR) or via gondolin build.
2. If assets are missing, fetch release assets directly from:
   • https://github.com/earendil-works/gondolin/releases/download/v<package-version>/gondolin-guest-<arch>.tar.gz

Blockers / prerequisites

Before we implement direct fetch robustly, we need a built-in way to determine Gondolin CLI version from the installed CLI.

• Today the CLI does not expose a stable version command (e.g. gondolin --version).
• We should wait for a built-in version check (and ideally an asset-fetch command) upstream.

Implementation plan (after upstream support exists)

• Remove @earendil-works/gondolin from dependencies.
• Keep GONDOLIN_GUEST_DIR support.
• Add downloader logic using detected CLI version + host arch mapping.
• Verify downloaded/extracted assets (kernel, initramfs, rootfs, optional manifest mapping).
• Update README/docs for the new bootstrap flow.
• Update CI to use the dependency-free path.

Acceptance criteria

• package.json has no runtime Gondolin dependency.
• Fresh machine/cold cache conversion works without importing Gondolin package internals.
• Docs clearly describe asset sourcing (gondolin build and/or direct release fetch).