Record BMC and BIOS firmware versions on the System at adopt

Follow-on from the x86 half of #1816, answering its "firmware inventory — BIOS/UEFI/BMC versions as
recorded Resource capabilities" scope item.

## Finding: the obvious source is the wrong one

`/redfish/v1/UpdateService/FirmwareInventory` on a live AMI MegaRAC / AST2600 BMC has two members,
and the BIOS one is a stub:

| Resource | Contents |
|---|---|
| `FirmwareInventory/BMC` | `Id`, `Name`, `Version: "1.90.00"`, `Updateable: true` |
| `FirmwareInventory/BIOS` | `Id`, `Name`, `Updateable: true` — **no `Version` property at all** |

The real BIOS version is published elsewhere, on the ComputerSystem:

```
/redfish/v1/Systems/Self → "BiosVersion": "P2.50"
```

So a driver that reads firmware versions from `FirmwareInventory` alone — the resource named for the
purpose — silently records no BIOS version.

## Why it is worth recording at all

Epic #1814 R3 records adopt-time facts on the System row, and firmware level is the kind of fact that
explains a reproduction failing on one host and not another. It is cheap: two GETs, no writes.

## Scope

One PR against adopt (#1823):

- Read BMC version from `FirmwareInventory`, BIOS version from `Systems/Self.BiosVersion`.
- Treat a missing value as absent rather than failing adopt — this is diagnostic metadata, not a
precondition.
- Record on the System row alongside the other adopt facts.

## Caveat for the implementer

This split is one vendor's behaviour, observed on one BMC. Do not assume the inverse mapping holds
elsewhere; read both sources and prefer whichever is populated.

Start at the adopt path in #1823 and inspect how adopt-time facts are recorded on the System row. Read both Redfish sources: FirmwareInventory for the BMC version and Systems/Self.BiosVersion for the BIOS version. Done means populated values are recorded when available, missing values do not fail adopt, and existing adopt behavior remains intact.

Written by the indexing model from the issue text.