deps: bump microsandbox 0.3.13 → 0.4.x to close hickory-proto advisory #30

[suchapalaver]

Advisory #30 (hickory-proto O(n²) name compression CPU exhaustion, fix in 0.26.1) is blocked by our exact pin:

# crates/baml-rt-tools/Cargo.toml
# microsandbox is a beta crate ("expect breaking changes"). Exact pin per ...
microsandbox = { version = "=0.3.13", optional = true }

microsandbox = "0.3.13" pulls microsandbox-network 0.3.13, which pins hickory-proto 0.25.2. The current registry version is microsandbox = "0.4.6". The upstream is on record warning about breaking changes between minor versions, so the bump needs validation.

What this does not close

Advisory #29 (hickory-proto NSEC3 closest-encloser proof, high severity) has no published fix anywhere as of 2026-05-23 — the vulnerable range is >= 0.25.0-alpha.3, <= 0.25.2 with first_patched: null. Bumping microsandbox to a 0.4.x that depends on hickory-proto 0.26.x will close #29 only because 0.26.x is outside the vulnerable range; if 0.4.x still pulls 0.25.x for some reason, #29 stays open. Verify against the lockfile after bumping.

Scope

microsandbox is gated behind the sandbox-provider feature on baml-rt-tools and is the syscall capability filter for the runner sandbox boundary (see CLAUDE.md "Local Setup (Linux)" — needs libcap-ng-dev). Check:

• baml-rt-tools/src/ for direct API surface that may have changed
• Sandbox-related e2e harnesses (just e2e-k8s, just e2e-k8s-cgroup-throttle)
• Whether the Dockerfile / Helm chart needs adjustments for new microsandbox versions

Verification

After bump:

• hickory-proto 0.25.2 should be gone from Cargo.lock
• Full workspace build + clippy + tests
• Sandbox-provider feature exercised in e2e-k8s lane

Follow-up from #531.

[suchapalaver]

Tracked under umbrella issue #575 (all 9 open Dependabot advisories).