controller: mark nodes stuck rebooting as degraded

[ptalgulk01]

What

Adds spec.rollout.rebootTimeoutSeconds to BootcNodePool. If a node stays in
the Rebooting state longer than this (e.g. it failed to boot the new image or
never rejoined the cluster), the controller reports it as degraded at the pool
level (degradedCount + Degraded/NodeDegraded). If 2+ nodes time out, the
rollout halts (Degraded/RolloutHalted).

The field is optional; when unset the controller waits indefinitely, so existing
behavior is unchanged.

Why

Today a node that reboots and never comes back sits in Rebooting forever. The
daemon can't report it (the node is down), so nothing surfaces the failure and
the reboot slot is held indefinitely. This covers issue #69 item 4 and the
"cross-distro bad image" scenario.
Fixes: #158

How it works

• driveRollout reclassifies timed-out Rebooting nodes into the degraded
  bucket and requeues the pool so the timeout fires without needing an event.
• findUnhealthySlots counts timed-out nodes toward the halt threshold — a node
  that failed to boot the target is a strong signal the image is bad, which is
  what the halt is meant to catch.

Design note

The controller reports at the pool level only. It has read-only access to
bootcnodes/status, and the daemon owns that condition (it auto-clears Degraded
on recovery). Marking the BootcNode's own condition would need an RBAC change and
a second writer for daemon-owned status. Happy to go that route instead if
maintainers prefer — flagging it here for input.

Testing

Unit tests for the timeout decision and slot classification, plus envtests for
the pool-degraded and rollout-halt paths.
Assisted-by: AI

[alicefr]

It looks great, many thanks for this work! Nice coverage also with the env tests