Handle a zero-worker Databricks cluster in _init_nodes

[jtwynne]

Fixes #2143

Problem

spark_rapids qualification --cluster <id> (and profiling, same path) on a Databricks
single-node cluster died with TypeError: 'NoneType' object is not iterable in _init_nodes.
databricks clusters get returns no executors entry for a cluster with no workers, and the
guard from #964 only regenerates the worker list when num_workers differs from the executor
count, which is 0 in both cases. The intended answer for this shape, the RuntimeError
"Invalid cluster: The cluster has no worker nodes" added in #240, never ran because
_init_nodes crashes before _verify_workers_exist.

A zero-worker cluster as databricks clusters get returns it (trimmed):

{"cluster_id": "...", "state": "TERMINATED", "num_workers": 0, "node_type_id": "Standard_NC16as_T4_v3",
 "driver_node_type_id": "Standard_NC16as_T4_v3",
 "spark_conf": {"spark.databricks.cluster.profile": "singleNode", "spark.master": "local[*, 4]"},
 "custom_tags": {"ResourceClass": "SingleNode"}}

Fix

_init_nodes in the Azure and AWS platform classes reads executors as an empty list when the
entry is absent, the same line in the same place in both files, right after the driver read
(driver gets its own absent-entry branch further down in the same method).

• The count stays 0, the guard is unchanged, the loop is a no-op and _verify_workers_exist
  raises the intended error. This restores the error, not single-node support; [BUG] --cluster on a zero-worker (single-node) Databricks cluster raises TypeError instead of the intended "no worker nodes" error #2143 notes
  driver-only evaluation as a separate request.
• Every shape with a nonzero worker count (terminated multi-node, autoscaling, executors
  present, executors empty) takes the path it takes today with the same log lines. Props
  with none of num_workers, autoscale and executors also move from the TypeError to
  the same RuntimeError.
• Widening the guard instead would have logged "Cluster configuration: executors count 0
  does not match the num_workers value 0. Using generated names." on the zero-worker path.
  ClusterBase._process_loaded_props is the hook for cleaning loaded properties (emr.py
  unwraps its Cluster wrapper there); neither Databricks class overrides it, so a default
  there is a new override per file that writes into the props, against one line at the read.

Tests

• TestDatabricksClusterWorkers in tests/spark_rapids_tools_ut/test_cluster.py, parametrized
  over the AWS and Azure platforms, loads the existing {aws,azure}-cpu-00.json fixtures with
  the executors entry removed and builds the cluster through load_cluster_by_prop (no CLI
  call on that path).
• test_zero_worker_cluster_raises_no_workers_error: num_workers: 0 raises the
  RuntimeError from _verify_workers_exist; on dev both platforms fail it with the
  TypeError.
• test_terminated_cluster_generates_workers: num_workers: 2 yields two generated workers,
  with and without the change.
• The whole spark_rapids_tools_ut set passes (313). pylint 10.00/10 and flake8 clean.

[greptile-apps]

Confidence Score: 5/5

The PR appears safe to merge, with the missing-executor case handled consistently across both Databricks implementations and covered by focused tests.

Summary

• Zero-worker clusters now reach the existing “no worker nodes” validation instead of failing while iterating over None.
• Terminated multi-worker clusters continue generating worker nodes from num_workers.
• Parameterized tests cover both Databricks platforms and both cluster shapes.

[cindyyuanjiang]

Thanks @jtwynne for this fix! Verified with a real Databricks-Azure cluster.