feat(baremetal): one command for what quietly breaks a server

[Denis-hamon]

What this adds

The things that quietly break a dedicated server are spread across five routes, and none of them is
where somebody would look. A machine left on the rescue system runs no service and says nothing;
monitoring switched off means OVHcloud will not call when a disk dies; a renewal switched off means
the server goes back at expiry.

ovhcloud baremetal doctor [service_name...] [--expiry-days 30] [--strict]

With no argument it checks every server of the account. Stacked on #258; only the last commit
belongs to this pull request.

What it found on a real fleet

35 servers, 8.3 seconds, 27 findings:

check	servers
booted on a rescue system	6
its rescue image is retired	3
monitoring off	11
hardware intervention refused	1
renewal state unreliable or off	5
work still running	1

Every one of these was verified against the API before being written as a check. Three more —
state != ok, powerState != poweron, planned interventions — fire on nothing here and are
included because they cost one field each and are exactly what this command exists to catch on a
fleet that is not this one.

Two things the fleet had to be asked

Testing bootType == "rescue" misses half of them. Six servers were booted on a rescue system:
three carried bootType: "rescue", and three carried bootType: "internal" on a boot entry
whose kernel is rescue-customer and whose description reads
Customer rescue system (Debian-10-based)[REMOVAL ON 2025-06-23] — a rescue image whose removal was
announced fourteen months ago. The type is the API's and it is wrong for that entry; the kernel is
not. So both are read, and the retired image is its own finding.

renew.automatic does not hold still. Twenty sequential reads of the same serviceInfos object
returned different values on five servers of the eight tested:

server	true	false
ns31563647	5	15
ns31563648	10	10
ns3217822	9	11
ns3217825	6	14
ns3217832	8	12
three others	20	0

The domain field proved each answer belonged to the server asked about, and monitoring on the
server object was stable ten out of ten — so it is that one field, on that one route. A health
check built on a single read of it reports a coin toss, and the first version of this command did
exactly that: it reported "automatic renewal is off" on three servers whose renewal was on.

It reads the field five times now. When the readings disagree, that is the finding — "the API gave
different answers about automatic renewal across 5 reads, so whether this server renews cannot be
established from here" — which is both true and the more serious problem. When they agree, the
finding says how it was established and asks the operator to confirm, because this route cannot give
certainty. Three readings would agree by chance one time in four; five bring that to about one in
sixteen. This is worth a look by the route's owner.

Design

• A server that could not be read is not a healthy server. If any server fails to answer, the
  command says so and reports no clean bill of health for the rest. It exists to be trusted when it
  says nothing is wrong.
• Every command named in a fix was checked against this binary's command tree. The first draft
  sent operators to set-boot, list-boots and list-planned-interventions, none of which exist —
  the same defect an earlier lot of this audit shipped in its own error message.
• The exit code stays 0 when findings are reported, because the command ran and answered, and
  every other command of this CLI reads a non-zero code as a failure. --strict turns findings into
  a failure for the pipeline gating on it, and has to be asked for rather than discovered.
• Findings are sorted worst-first then grouped by server, and --filter works on them
  (--filter 'severity=="critical"').

Verified

11 sabotages against the checks, 11 red — including one that reverts the rescue detection to the
type alone, one that decides the renewal from a single read, and one that lets an unreadable server
pass for healthy.