Remove lost+found from named volume EXT4 images

[sylvaincombes]

What

Remove lost+found from freshly created named volume EXT4 images by calling
formatter.unlink(path: FilePath("/lost+found")) before formatter.close() in
VolumesService.createVolumeImage.

Why

The EXT4.Formatter in containerization correctly creates lost+found for
general-purpose e2fsck compatibility. Named container volumes, however, are never
checked with e2fsck — and many widely-used database images treat a non-empty
volume root as a fatal error at initialization time:

initdb: error: directory "/var/lib/postgresql/data" exists but is not empty
initdb: detail: It contains a lost+found directory, perhaps due to it being a mount point.

Affected images include Postgres, MySQL, Elasticsearch, MongoDB, and any image
whose entrypoint runs initdb-style initialization against the raw volume mount point.

Docker Desktop, Colima, and OrbStack all present fresh named volumes as empty
directories. This fix restores that parity and unblocks a broad class of
real-world use cases.

Safety

lost+found is not required for EXT4 to function. If e2fsck is ever run on a
volume, it recreates lost+found automatically when it finds it missing. No data
loss, no corruption risk. Only newly created volumes are affected; existing
volume images are unchanged.

The fix is at the right semantic layer: VolumesService is where the decision
that "this EXT4 image is for a container named volume" belongs. The
containerization library comment ("required for e2fsck to pass") remains
correct for its own scope.

Tests

Two new tests in Tests/ContainerResourceTests/VolumeImageTests.swift:

• formatterCreatesLostAndFoundByDefault — baseline confirming the default
  formatter behaviour that this fix deliberately overrides
• volumeImageHasNoLostAndFound — confirms the root directory is empty after
  the unlink, using EXT4.EXT4Reader.listDirectory

Fixes #1730