Redfish driver must handle vendor-divergent writes: If-Match, AMI FutureState URI, pending-settings

Follow-on from the x86 half of #1816. Implementation constraint on #1818 (the Redfish OOB driver).

## Finding

A spec-conformant Redfish client fails against real AMI MegaRAC firmware (AST2600, BMC FW 1.90.0,
`RedfishVersion 1.8.0`) on three independent counts, all observed live.

### 1. Every PATCH requires an `If-Match` ETag

A PATCH without the header is rejected outright:

```
HTTP 428
Ami.1.0.PreconditionHeaderMissing
"The request did not provide the required precondition, such as an If-Match or If-None-Match header."
```

**This is the most broadly applicable of the three** — it is not specific to boot. Any property the
driver ever writes needs a read-then-write-with-ETag cycle, which also means handling the 412 race
when the ETag has moved.

### 2. Boot properties are read-only on the standard resource

PATCHing `Boot` on `/redfish/v1/Systems/Self` returns `Base.1.5.PropertyNotWritable` per property,
plus a vendor message redirecting to a non-standard URI:

```
Ami.1.0.OperationSupportedInFutureStateURI
"Support of this Operation for Boot Properties is moved to FutureState URI(/redfish/v1/Systems/Self/SD)"
```

The same PATCH against `/redfish/v1/Systems/Self/SD` succeeds with `HTTP 204`. The `SD` resource is
also the only place `BootSourceOverrideTarget@Redfish.AllowableValues` is published — the standard
System resource advertises no allowable values at all.

### 3. Read-after-write on the standard resource returns a false negative

After a successful `204` setting `Once`/`Pxe`:

| Resource | `BootSourceOverrideEnabled` | `BootSourceOverrideTarget` |
|---|---|---|
| `/redfish/v1/Systems/Self/SD` | `Once` | `Pxe` |
| `/redfish/v1/Systems/Self` | `Disabled` | `None` |

It is a pending-settings model. A driver that verifies via the standard resource concludes the write
failed when it succeeded.

Two smaller notes from the same exercise:

- The BMC silently defaulted `BootSourceOverrideMode` to `Legacy`, a value never sent.
- `BootSourceOverrideMode` has no null in its allowable set (`Legacy|UEFI`), so once written it
cannot be restored to an unset state.

## Why this is a driver concern even though boot override is an epic non-goal

Epic #1814 lists boot-order changes as a non-goal, so the *boot* half is informational. But finding 1
applies to **every** write the driver makes, and findings 2–3 are the concrete evidence that this
vendor's Redfish deviates in ways a naive client cannot detect — it gets a plausible-looking wrong
answer, not an error.

## Scope

One PR against the #1818 seam:

- ETag read-then-write with 412 retry, for all writes.
- A capability/quirk probe so vendor divergence is detected at adopt rather than mid-Run.
- Verification that reads the resource the write targeted, not the canonical one.
- Tests covering 428, 412, and the pending-settings read-back.

## Evidence

Live against a real BMC on 2026-08-04. Boot override was set and restored; final state cross-verified
via IPMI (`chassis bootparam get 5` → `0000000000`, "No override").

Start at the #1818 Redfish OOB driver seam and trace the shared write path used by the driver. Use the reported 428, 412, AMI FutureState URI, and pending-settings behavior as the cases to cover; done means all writes use ETag retry handling, vendor divergence is detected at adopt, targeted resources are verified, and the listed tests cover those responses.

Written by the indexing model from the issue text.