bootc-generic-growpart fails on an mdraid root: /sys/class/block/<md>/partition does not exist

## Summary

`bootc-generic-growpart.service` fails on every boot when the root filesystem is
on an md (software RAID) device. It derives the partition number by reading
`/sys/class/block//partition`, which an md device does not have.

Not fatal — the rest of the system comes up and works — but the unit is
permanently failed, so `systemctl is-system-running` reports `degraded` on every
such machine.

## Versions

- `bootc 1.16.10`
- Base image `quay.io/fedora/fedora-bootc:44`
- Installed with Anaconda (`anaconda-iso` from bootc-image-builder), kickstart
below

## Reproducer

Kickstart fragment — RAID1 root and RAID1 `/boot`, with a plain (non-RAID) ESP
on the first disk:

```
clearpart --all --initlabel --disklabel=gpt
ignoredisk --only-use=sda,sdb

part /boot/efi --fstype=efi --size=600 --ondisk=sda

part raid.11 --size=2048 --ondisk=sda --fstype=mdmember
part raid.12 --size=2048 --ondisk=sdb --fstype=mdmember
raid /boot --level=RAID1 --device=boot --fstype=ext4 raid.11 raid.12

part raid.21 --size=16384 --ondisk=sda --fstype=mdmember
part raid.22 --size=16384 --ondisk=sdb --fstype=mdmember
raid / --level=RAID1 --device=root --fstype=ext4 raid.21 raid.22
```

The install itself succeeds and the machine boots normally.

## Observed

```
× bootc-generic-growpart.service - Bootc Fallback Root Filesystem Grow
Loaded: loaded (/usr/lib/systemd/system/bootc-generic-growpart.service; static)
Active: failed (Result: exit-code)
Process: 1014 ExecStart=/usr/libexec/bootc-generic-growpart (code=exited, status=1/FAILURE)

bootc-generic-growpart[1014]: Backing device: /dev/md126
bootc-generic-growpart[1018]: cat: /sys/class/block/md126/partition: No such file or directory
systemd[1]: bootc-generic-growpart.service: Main process exited, code=exited, status=1/FAILURE
```

Layout at the time:

```
md126 : active raid1 sda3[0] sdb2[1]
2094080 blocks super 1.2 [2/2] [UU] -> /boot
md127 : active raid1 sda2[0] sdb1[1]
16759808 blocks super 1.2 [2/2] [UU] -> /sysroot
```

```
$ systemctl is-system-running
degraded
$ systemctl list-units --state=failed --no-legend
● bootc-generic-growpart.service loaded failed failed Bootc Fallback Root Filesystem Grow
```

## Expected

Either grow the array's underlying member partition, or recognise that the
backing device is not a partition and exit successfully with a log line saying
growing was skipped. A permanently failed unit on an otherwise healthy machine
makes `degraded` useless as a signal.

## Related

The same `/sys/class/block//partition` assumption appears in `bootupd`,
where it is fatal rather than cosmetic: an install with the ESP itself on mdraid
fails at `bootupctl backend install` with
`Failed to read /sys/class/block/md125/partition`. That is
[#947](https://github.com/bootc-dev/bootc/discussions/947), open since December
2024. This report is the non-fatal sibling, and is worth noting only because two
independent components make the same assumption.

## Workaround

Size the root array explicitly in the kickstart rather than relying on
`--grow`, so nothing is lost by growpart not running.

## Context

Found while verifying whether a bootc install onto an mdraid root works end to
end. It does, including booting from the surviving disk after detaching the
first one — this unit is the only thing left failing.

Inspect /usr/libexec/bootc-generic-growpart and bootc-generic-growpart.service, then reproduce the failure on an mdraid-root layout or trace the /sys/class/block lookup. Done means the service no longer fails for an md device: it either grows the appropriate member partition or exits successfully with a log that growth was skipped.

Written by the indexing model from the issue text.