[Bug]: Virtiofs — untarring buildroot archives to a VirtioFS-mounted case-sensitive APFS volume produces corrupted symlinks

### I have done the following

- [x] I have searched the existing issues
- [x] If possible, I've reproduced the issue using the 'main' branch of this project

### Steps to reproduce

## Steps to reproduce

1. On macOS, create or prepare a **case-sensitive APFS** volume and copy some tarball source archives (for example buildroot `*.tar.xz` / `*.tar.gz`) onto that volume.
2. Start a container from an Ubuntu 22.04 (x86) image on Apple Container and mount the case-sensitive APFS volume into the container using a bind/volume mount (this host → container mount ends up backed by VirtioFS with “Enable VirtioFS accelerated directory sharing” / default Apple container settings).
3. Inside the container, `cd` to the mounted directory and run `tar -xf .tar.xz` (or `tar -xf .tar.gz`) to extract the archive onto the VirtioFS mount.
4. Observe extracted files that were symlinks in the archive are created incorrectly (zero-byte files or filenames/targets replaced with question marks or otherwise corrupted). Extracting the same archive to a directory that sits on the container’s local filesystem (not the VirtioFS mount) succeeds and symlinks are created correctly.

### Current behavior

When extracting archives (tar.xz / tar.gz) that contain symbolic links into a directory backed by VirtioFS (case-sensitive APFS host volume mounted into the container), `tar` reports permission/open errors for symlink entries and the filesystem ends up with zero-byte files or filenames full of question marks instead of valid symlinks.

Example from my case: an archive contained entries like

```
lrwxrwxrwx 1 root root 40 Dec 18 2021 snd_soc_apq8016_sbc.conf -> ../Qualcomm/apq8016-sbc/apq8016-sbc.conf
```

After extraction to the VirtioFS mount the extracted entry is corrupted (file of size 0 with no permissions or a name/target represented as `???????`), while extracting the same archive to a local (non-virtiofs) directory inside the container works normally.

This behavior is effectively the same class of symptom described in an earlier report (issue #6277). ([[GitHub](https://github.com/docker/for-mac/issues/6277)](https://github.com/docker/for-mac/issues/6277))

### Expected behavior

Symbolic links inside the archive should be recreated correctly when extracted into a directory that is mounted from the host via VirtioFS. `tar` should not report permission denied for creating symlinks, and the extracted symlink entries should have the same link target and permissions as they do when extracted onto a non-VirtioFS filesystem.

### Environment

```markdown
- OS: macOS 26.2 (25C56)
- Xcode: /
- Container: container CLI version 0.9.0 (build: release, commit: 3e49dce)
- Container image: `ubuntu:22.04` (x86)
- Host filesystem: case-sensitive APFS volume (created on the Mac and mounted into the container)
- Share mechanism: VirtioFS (host → container mount / volume)
- Archives tested: buildroot `*.tar.xz` and other `tar.gz`/`tar.xz` archives that contain symlinks
- Behaviour: extraction to local container filesystem (not VirtioFS) — OK; extraction to VirtioFS mount — symlinks corrupted
```

### Relevant log output

```shell
- `tar` error example (representative):

tar: ./some/path/.bin/katex: Cannot open: Permission denied
...
---------- 1 root root 0 Apr 12 15:04 katex

- Example archive symlink (from an affected archive):

lrwxrwxrwx 1 root root 40 Dec 18 2021 snd_soc_apq8016_sbc.conf -> ../Qualcomm/apq8016-sbc/apq8016-sbc.conf

(After extraction to VirtioFS mount the entry appears as a zero-byte file or as corrupted name/target.)
```

### Code of Conduct

- [x] I agree to follow this project's Code of Conduct