test(e2e): pin the contracts a README walkthrough expects (EAI-8024)

[fredespi]

Walking the public README end to end on an MI300X pod turned up thirteen places
where the CLI does not do what the README leads a reader to expect. This adds
end-to-end coverage for them. It is test-only — no product behaviour changes.

Each scenario asserts the behaviour the README promises and is registered as an
expected failure in expectations.toml, citing its ticket. CI stays green, and
the day a defect is fixed its row becomes a stale XPASS and deletes itself.

Pinned as expected failures

Ticket	What the scenario pins	Lane
EAI-8011	The help offers rocm serve qwen2.5-7b-instruct, which is neither a name the model listing knows nor an owner/repo reference	no-GPU
EAI-8011	The help describes running rocm with no subcommand as opening the dashboard — what it also says rocm dash does	no-GPU
EAI-8010	rocm update --dry-run is refused as a usage error, though the README documents --apply and --dry-run as independent	no-GPU
EAI-8019	serve --help advertises cpu_only and the command refuses it for being cpu_only	no-GPU
EAI-8020	The diagnosis and the fix preview print different verification steps for the same remedy	no-GPU
EAI-8009	Chatting locally without naming a model ignores a ready local server that is not the built-in assistant model	no-GPU
EAI-8014	Uninstall reports completion while leaving the servers it manages running, having deleted the records needed to stop them	no-GPU
EAI-8015	A remedy tells the user to join UNKNOWN — the group-lookup failure, not a group	MI300X
EAI-8020	The diagnosis and the fix propose adding the user to different groups	MI300X
EAI-8021	A device the user can already read and write is still offered as a group-permission cause	MI300X
EAI-8016	A second server is given the default address even when it is already in use	MI300X

Two ship as guards, with no expected-failure row

EAI-8007 (a stop that worked reporting it stopped nothing) and EAI-8006
(--gpu auto selecting none) were reproduced on the pod but hold correctly on
every lane available here — EAI-8007 against both a plain registered process and
a real vLLM serve, EAI-8006 because the runner's amd-smi executes where the
pod's bundled one could not. A row would be a stale XPASS and would fail the
lane, so their scenarios ship as guards for the contract instead. Both tickets
keep the pod observation.

Two are not covered, deliberately

EAI-8017 and EAI-8018 both need a working Lemonade install, and Lemonade's
launcher cannot start on either lane: on the MI300X runner it wants GLIBC_2.38
and GLIBCXX_3.4.32, which that OS does not have, and in a plain container it
wants libdrm_amdgpu.so.1. Each dies before reaching the behaviour under test,
so scenarios for them passed while proving nothing. They were removed rather
than shipped as false coverage, and stay on their tickets.

Harness additions

Confined to the test crate: removing environment variables from the child (the
existing helper only sets them), stat and id shims scoped to one device path
so a device-group state can be arranged rather than hoped for, and a child
process a scenario owns and registers as a managed service so it can ask whether
the product stopped it — asserted before teardown, which would otherwise clean up
after the product and hide the defect.

Two caveats worth stating. A substituted stat answer proves how the CLI handles
an unnameable group, not that a given host produces one; the provenance for that
is the pod. And the device-group scenarios need a real device node, so they run
on the GPU lane only.

Test plan

• No-GPU lane, three independent runs: 52 scenarios, 10 xfail, 0 XPASS, 0
  unexpected failures.
• Full MI300X lane (e2e-selfhosted, no name filter, so expectations resolve
  normally): 64 scenarios, 16 xfail, 0 XPASS, 0 unexpected failures.
• Every new scenario was read individually to confirm it fails for the reason its
  row states, rather than because a step is miswired.
• cargo clippy --workspace --all-targets -D warnings, the workspace tests, and
  cargo test -p e2e-cucumber --lib pass in a Linux container.

Four rows were corrected from what the GPU dispatches measured rather than left
as first written, which is why two became guards and two scenarios were dropped.

[juhovainio]

Reviewed this against gh pr diff 241 — good, well-documented test-only PR (no product code touched), and I cross-checked all 13 new scenarios against their expectations.toml rows and lane tags; that bookkeeping is consistent and the reasoning for each row (including the two tickets deliberately left uncovered because Lemonade can't start on either available lane) holds up.

One real bug in the new harness code, though: advertised_device_policies in serving_steps.rs reads the wrong flag's help text, which breaks the exact scenario it's meant to support. Left as an inline comment with a fix suggestion. Also left a smaller nit on find_bool in diagnose_steps.rs that's not blocking but worth a look.