/dev/vdb missing inside VM — guest init does not mount devtmpfs

## Symptom

`/dev/vdb` (the 10 GB container disk) does not exist inside the VM even though the kernel sees both disks in `/proc/partitions`. Container.Init fails to mount the container disk, so `apt-get install` and other container writes land on the tiny 256 MB guest rootfs (`/dev/vda`) instead.

## Root Cause

The guest init process (`boxlite-guest`) mounts tmpfs on `/tmp`, `/var/tmp`, and `/run` via `mount_essential_tmpfs()` in `guest/src/mounts.rs`, but **never mounts devtmpfs at `/dev`**. Without devtmpfs, the kernel has no mechanism to auto-populate block device nodes — `/dev/vda` exists only because the rootfs image has it baked in, but `/dev/vdb` has no pre-existing node.

## Impact

- **Container disk is never mounted.** `BlockDeviceMount::mount()` in `guest/src/storage/block_device.rs` correctly checks `device.exists()` and returns `Storage("Block device not found: /dev/vdb")`.
- **Container writes go to guest rootfs.** The 256 MB vda fills up quickly, causing `apt-get` and similar tools to fail with ENOSPC.
- **Affects all boxes** that use a separate container disk (which is the default configuration).

## Fix

Mount devtmpfs at `/dev` early in guest startup (before the gRPC server starts). The kernel will then auto-populate all block device nodes discovered via virtio-blk.

```rust
mount(Some("devtmpfs"), "/dev", Some("devtmpfs"), MS_NOSUID, Some("mode=0755"))
```

This should run before the existing tmpfs mounts and before `GuestServer::run()`.

Start in guest/src/mounts.rs at mount_essential_tmpfs(), then inspect the existing startup sequence before GuestServer::run(). Ensure devtmpfs is mounted at /dev before the existing tmpfs mounts and guest server startup. Done means /dev/vdb is populated and BlockDeviceMount::mount() can mount the container disk instead of writing to /dev/vda.

Written by the indexing model from the issue text.