KVM launcher panics (InvalidAscii) after #152 when the runner's /etc/resolv.conf has more than one line #156

Summary

Since #152 (725f799), launcher/entrypoint.sh exports the runner's whole
/etc/resolv.conf as SANDBOX_RESOLV_CONF and the launcher forwards it to the
guest through krun_set_exec's env. libkrun appends every guest env entry to
the kernel command line (src/libkrun/src/lib.rs collapse_str_array, then
src/vmm/src/builder.rs kernel_cmdline.insert_str(krun_env).unwrap()), and
linux-loader's Cmdline rejects any character outside ' '..='~' with
InvalidAscii. Docker's generated resolv.conf is multi-line (comments,
nameserver, options ndots:0), so the launcher panics before the guest boots:

[launcher] Starting microVM...
thread '<unnamed>' panicked at src/vmm/src/builder.rs:594:53:
called `Result::unwrap()` on an `Err` value: InvalidAscii
...
  12: krun_start_enter
thread caused non-unwinding panic. aborting.

sandbox-runner then restart-loops (exit 139) and docker compose up fails
with "dependency failed to start: container sandbox-runner is unhealthy".

Environment

• Docker Compose, default KVM path (sandbox-runner-baked), KVM_ENABLED=true
• libkrun 1.19.0 (Fedora 43 package in the launcher image)
• Runner /etc/resolv.conf as generated by Docker Engine (11 lines, one
  nameserver 127.0.0.11)

Reproduce

Build main at 725f799, docker compose up --build. Any runner whose
/etc/resolv.conf contains a newline (i.e. every Docker container) hits it.
tests/kvm_guest_dns.sh does not catch it because it never invokes libkrun.

Workaround

Hand the guest a single line:

export SANDBOX_RESOLV_CONF="$(grep -E '^[[:space:]]*nameserver[[:space:]]' /etc/resolv.conf | head -n 1)"

Suggested fix

Encode the resolver handoff so it survives the kernel command line: e.g. pass
nameserver/search/options entries as separate single-line env vars, or
join lines with a printable separator that api/src/guest-dns.sh expands back
(and reject any remaining control characters in the launcher instead of
letting libkrun unwrap()). Also worth noting: the kernel command line has a
hard size limit, so forwarding comments is fragile even once newlines are handled.