`additionalDisks`: a disk whose name is longer than 11 characters is silently reformatted on every boot

### Description

An `additionalDisks` entry whose name is too long to fit in the filesystem label is reformatted on every boot, destroying whatever was stored on it. There is no warning, and the disk still mounts normally afterward, so the data loss is silent.

### Mechanism

`pkg/cidata/cidata.TEMPLATE.d/boot.Linux/05-lima-disks.sh` decides whether a disk needs first-time setup by testing for a by-label device node, then formats it with a label derived from the same name:

```bash
if [[ ! -b "/dev/disk/by-label/lima-${DISK_NAME}" ]]; then
if $FORMAT_DISK; then
echo 'type=linux' | sfdisk --label gpt "/dev/${DEVICE_NAME}"
mkfs.$FORMAT_FSTYPE $FORMAT_FSARGS -L "lima-${DISK_NAME}" "/dev/${DEVICE_NAME}1"
fi
fi
```

`mkfs.ext4` caps volume labels at 16 bytes and truncates silently. The `lima-` prefix takes 5 of those, so any name longer than 11 characters is written with a label that does not match the path the guard tests. The guard is therefore true on every boot and `mkfs` runs again.

The mount at the end of the same loop uses the device path, not the label, so the disk always mounts and nothing looks wrong.

The limit depends on the filesystem: ext4 allows 16 bytes, xfs only 12 (so xfs breaks at names longer than 7 characters), btrfs 255. `fsType` is user selectable, so a single hardcoded constant would not be a correct fix.

### Reproduction

```yaml
additionalDisks:
- name: "myproject-images" # 16 characters, over the limit
format: true
fsType: ext4
```

Start the instance, write a file into `/mnt/lima-myproject-images/`, restart, and the file is gone. In the guest:

```console
$ blkid /dev/vdb1
/dev/vdb1: LABEL="lima-myproject-i" ... # truncated to 16 bytes

$ ls /dev/disk/by-label/
lima-myproject-i # not lima-myproject-images

$ sudo tune2fs -l /dev/vdb1 | grep 'Filesystem created'
Filesystem created:
```

### Possible fix

Stop identifying the disk by its filesystem label. Treating "the partition already carries a filesystem" as the first-time-setup signal removes the length limit and, importantly, still recognises disks formatted by older Lima versions, so an upgrade cannot trigger the very data loss it is meant to fix. A GPT partition label (36 characters, `/dev/disk/by-partlabel/`) can carry the full name for user convenience.

Rejecting over-long names would be the other option, but it would break configs that work correctly once identification no longer depends on the label.

I have a patch along these lines and can open a PR if this direction sounds right.

Start in pkg/cidata/cidata.TEMPLATE.d/boot.Linux/05-lima-disks.sh and inspect the by-label guard, partition setup, and mkfs call. Reproduce with the myproject-images ext4 configuration, then verify that an existing filesystem is recognised across reboot, including one with a truncated legacy label, and that its files persist.

Written by the indexing model from the issue text.