scaleset: fix reapTimedOutRunners deadlock on creating instances

[benoit-nexthop]

reapTimedOutRunners skipped runners in pending_delete/pending_force_delete/deleting/deleted status, but not creating/pending_create. When a runner's scale-set-level bootstrap timeout elapsed while its instance was still being created in the provider (e.g. a cloud provider deploy running long due to host iowait) and it had never joined GitHub, this tried to transition the instance straight from creating to pending_delete. That transition isn't allowed (InstanceCreating only permits -> error or -> running), so UpdateInstance returned a BadRequestError.

That error was treated as fatal: reapTimedOutRunners immediately unlocked everything it had processed so far and returned early, and its caller (consolidateRunnerState) aborted the rest of consolidation for that scale set on any error. This meant a single runner still legitimately booting (just slow) could block reaping of every other eligible runner in the same scale set, repeating every consolidate tick (~5 min) until the poisoned runner resolved on its own via the provider worker's separate create-timeout handling.

Observed in our prod cluster: invalid instance status transition from creating to pending_delete logged repeatedly for a scale set while the underlying cloud provider was slow.

Fix:

• Skip InstanceCreating/InstancePendingCreate in reapTimedOutRunners, mirroring the same skip already done later in consolidateRunnerState. The provider worker owns create timeouts/failures for these instances.
• Don't let one runner's transition error abort the whole batch: log it, release just that runner's lock, and keep processing the rest instead of returning early.

[gabriel-samfira]

This is great! Thanks!