Decide whether teardown takes a second Host Interface observation

Follow-up from #1847 / PR #1890. Raised in adversarial review of ADR-0547.

## Problem

ADR-0547 justifies recording the Host Interface posture in `systems.byo_adopt_facts` on its value
**at incident time**: a vmcore accompanied by an unexplained power event, or a host that returns
with different firmware, needs to know whether the unauthenticated host-OS→BMC path existed.

The design takes only **one** datapoint, at adopt. Nothing observes the posture again after the
run. So the recorded fact answers "was the path open when we took the machine?" and cannot answer
"did it change while we had it?" — and a kernel reaching its own BMC is exactly the actor that
could change it. The stated incident-time value is therefore partly unbacked by the design that
claims it.

This is **not** the comparison ADR-0547 rejects. That record declines to make the posture a
*compared* fact at teardown, correctly: a changed Host Interface state does not by itself mean the
ADR-0541 restore failed, and turning it into a restore-verification input would put a host into
`restore_incomplete` and a cordon over a difference that is not a restore defect. A second
**uncompared** observation is a different thing — it is a datapoint an incident can read, with no
control flow hanging off it.

## Evidence

- `docs/adr/0547-host-interface-in-band-bmc-path.md` — Decision, question 3: the incident-time
justification, and the sentence rejecting comparison.
- `docs/design/m4-byo-host.md` — the M4 migration claims `systems.byo_adopt_facts jsonb` (entry 2,
`0112_resources_kind_byo_host.sql`); #1823 owns the adopt-time write.
- ADR-0541's teardown step 3 is already a third caller of the shared precondition module and
already re-reaches the host out-of-band after the power-cycle, so a second read has an existing
place to sit and needs no new OOB call site.

## Expected outcome

Decide, and implement or record the refusal:

- Whether teardown takes a second Host Interface observation and writes it beside the adopt one
(e.g. an `at_teardown` key rather than overwriting `at_adopt`), so a difference is *visible* to
an operator reading the System.
- Explicitly **no** control flow on the difference: it must not feed restore verification, must not
set `restore_incomplete`, and must not cordon. If the two disagree, the record says so and
nothing else happens.
- If a teardown that never runs (a dead worker, a cordoned host) leaves only the adopt datapoint,
that is the expected degraded case and should be readable as "no post-run observation", not as
"unchanged".
- If the answer is no, an amendment to ADR-0547 qualifying the incident-time claim to what one
datapoint actually supports.

The adopt-time write lands in #1823; teardown in #1830.

Blocked by #1823
Blocked by #1830

Read docs/adr/0547-host-interface-in-band-bmc-path.md and docs/design/m4-byo-host.md, then review the adopt-time and teardown work in #1823 and #1830. Decide whether teardown records an uncompared second observation or whether ADR-0547 must be amended; done means the decision is recorded and any implementation preserves the stated no-control-flow behavior.

Written by the indexing model from the issue text.