Adopt the role controller on a live fleet and set its defaults #184

The last piece of the dynamic regrading epic: decide the collection's defaults and bring the role controller into use on a real fleet.

Defaults. The controller stays off unless github_runner_cluster_role_controller is true, and dry-run unless FLEET_ROLE_DRY_RUN is set false, so a consumer that upgrades changes nothing. No host is eligible or pinned by default. The target voter count defaults to 3. The README's server selection section is rewritten for the case where the controller manages roles: inventory order gives the first role only.

Memory-pressure regrading (#140). The controller refuses to change a role while any voter is below full, and uses the regrade core's own memory signals, so regrading and role changes share one Lease and never step together. That makes regrading a prerequisite on every eligible server, which strengthens the case in #140 for making it the default for a server; the trial #140 asks for can include native servers once the systemd actuator has shipped. #140 stays its own decision.

Adoption on a live fleet. In order:

1. Mark the eligible hosts and stage every native one as a standby server with the service left stopped (the role's native start flag off), so certificates and configuration exist before any promotion. Every server's certificate gains the eligible hosts' names, which takes one rolling restart of the servers, one at a time through the role's quorum guard.
2. Run the probe and the controller in dry-run for at least one window on the live cluster, read fleet-role-status against hand readings on each host, and correct any probe that disagrees before going on.
3. Do the first swap by hand through the controller's command while the owner watches, with a fresh snapshot.
4. Turn dry-run off.

A fleet that has decided particular servers stay voters whatever their link keeps that decision with github_runner_cluster_voter_pinned; dynamic regrading otherwise moves votes off a host whose path is poor, which is its purpose, so each pin is set in the fleet's inventory with a comment saying why.

Tests: the fleet's own --check run before each step, and the controller's dry-run output read against the hosts. No collection change here beyond docs and defaults, so its CI is the existing suites.