fixed deps problem with virtio and vm-memory libs

[ramirolaso]

Root cause (two separate issues stacked):

1. virtio-queue = "0.14" was an unused dependency — it declared vm-memory = "0.16.0" (i.e., ^0.16), silently pulling vm-memory 0.16.2 into the graph alongside our 0.17.x.
2. vm-memory 0.17.2 is a compatibility shim — it was published as a thin wrapper around vm-memory 0.18.0 (via package = "vm-memory" aliasing). When cargo install did a fresh resolution without the workspace lock, "0.17"
   resolved to 0.17.2 (the shim), which brought in 0.18.0 types — incompatible with linux-loader's cap at <=0.17.1.

Changes:

• Removed virtio-queue = "0.14" — it was unused in the entire codebase and was the source of vm-memory 0.16.2 in the dependency graph.
• Pinned vm-memory = "=0.17.1" — prevents fresh resolution from picking the 0.17.2 shim. Since both our dep and linux-loader 0.13.2 (which requires >=0.16.0, <=0.17.1) now resolve to exactly 0.17.1, there is one version of
  vm-memory in the entire graph.

[Copilot]

Pull request overview

This PR fixes a dependency resolution issue caused by two stacked problems: an unused virtio-queue dependency pulling in vm-memory 0.16.2, and vm-memory 0.17.2 being a compatibility shim that forwards to 0.18.0, conflicting with linux-loader's requirement for <=0.17.1.

Changes:

• Removed unused virtio-queue = "0.14" dependency that was causing vm-memory 0.16.2 to enter the dependency graph
• Changed vm-memory from "0.17" to "=0.17.1" to prevent cargo from resolving to the 0.17.2 shim version

Reviewed changes

Copilot reviewed 1 out of 2 changed files in this pull request and generated 1 comment.

File	Description
Cargo.toml	Removed unused virtio-queue dependency; pinned vm-memory to exact version 0.17.1
Cargo.lock	Removed virtio-queue and vm-memory 0.16.2 entries; consolidated thiserror to single version 2.0.18; updated all vm-memory references to 0.17.1

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Using exact version pinning (=0.17.1) for vm-memory in a library crate can cause dependency conflicts for downstream consumers. Since void-box has a lib.rs and exports a public API, other crates depending on it may encounter resolution failures if they need a different vm-memory patch version.

Consider using an upper bound constraint instead (e.g., ">=0.17.0, <0.17.2") or upgrading both void-box and linux-loader to vm-memory 0.18 if compatible. If exact pinning is necessary as a short-term fix, document this limitation and plan for a proper resolution.

Suggested change

	vm-memory = { version = "=0.17.1", features = ["backend-mmap"] }
	vm-memory = { version = ">=0.17.0, <0.18.0", features = ["backend-mmap"] }