[Feature] Distinguish required runtime members from optional federated nodes

[data-angel]

Part of #9.

Problem

LLooM currently treats every configured cluster.nodes entry as part of one global health set. This conflates required members of a distributed runtime with optional federated nodes that may legitimately be offline.

As a result, lloom cluster doctor can report the entire cluster unhealthy because an optional workstation or experimental node is absent even though all nodes required by the selected runtime are healthy.

Proposed contract

• Represent node requiredness explicitly, either through node availability metadata, runtime dependency scopes, or both.
• Compute runtime readiness from that runtime's actual placement and serving dependencies.
• Report optional offline nodes as warnings rather than global failures.
• Add scoped diagnostics such as lloom cluster doctor --runtime <runtime-id>.
• Preserve a whole-topology view without making optional federation equivalent to quorum.

Acceptance criteria

• Doctor output distinguishes healthy, management-degraded, optional-offline, and unavailable states.
• A required placement node being unavailable fails the scoped runtime check.
• An optional federated node being offline does not fail an unrelated runtime check.
• Dashboard and JSON output expose the same requiredness and state semantics.
• Existing single-node and replicated-model behavior remains compatible.

Non-goals

• Automatically starting optional hardware.
• Treating all federation as a high-availability cluster.