PR Description: Topology Configuration Infrastructure

What type of PR is this?

/kind feature
/kind api

What this PR does / why we need it

This PR implements the foundational infrastructure for topology-aware scheduling in Grove by adding operator-level configuration and validation for topology support.

Key Changes:

1. Operator Configuration: Adds TopologyConfiguration to operator config with:

   • enabled field to enable/disable topology features (defaults to false)
   • name field to specify ClusterTopology resource name (defaults to "grove-topology")
   • Validation that topology name is required when enabled

2. Startup Validation: Operator validates topology configuration at startup:

   • When topology.enabled=true, verifies ClusterTopology resource exists
   • Exits with clear error if enabled but ClusterTopology not found
   • Prevents operator from running in invalid topology state

3. RBAC Permissions: Updates cluster role to grant Grove operator read access to ClusterTopology resources

4. Documentation: Adds TopologyConfiguration section to operator API reference

5. Sample Configuration: Provides example topology configuration YAML

Why This Matters:

Topology-aware scheduling is critical for Grove's multi-node inference workloads because:

• Network locality improves high-bandwidth communication between leaders and workers
• Coordinated placement of related components (model shards) improves performance
• Minimizing network hops between inference components reduces latency

This PR establishes the operator-side foundation that will enable workloads to specify topology constraints in future PRs.

Special notes for your reviewer

Implementation Scope:

This is Phase 1 of topology-aware scheduling implementation, focusing on operator configuration infrastructure. It includes:

• Operator config schema and defaults
• Validation logic for topology settings
• Startup-time ClusterTopology existence checks
• RBAC permissions

What's NOT in this PR:

Future PRs will add:

• ClusterTopology CRD definition and controller
• TopologyConstraint fields in PodCliqueSet/PodClique APIs
• Webhook validation for topology constraint hierarchy
• PodGang topology constraint translation

Testing Notes:

• Added unit tests for config defaults and validation
• Tests verify proper error messages and default values
• Startup validation tested via config validation tests

Migration Path:

• Default topology.enabled=false ensures backward compatibility
• Existing workloads unaffected until topology explicitly enabled
• No breaking changes to existing APIs

Does this PR introduce an API change?

Add topology configuration to Grove operator config, enabling foundational support for topology-aware scheduling. Topology support is disabled by default and requires explicit configuration.

Additional documentation

See design document: docs/designs/topology.md

Operator configuration reference updated with TopologyConfiguration section showing:
- How to enable topology support
- How to configure ClusterTopology resource name
- Validation requirements and startup behav