PCP-6874: Feat: LXD workload cluster / Host Control Plane cluster / maintenance mode

[Kun483]

What this PR does / why we need it

1. Cherry picked the LXD (DHCP) / HCP experimental features
2. Fixed make docker-push-all
3. Removed spectro folder
4. Added WLC and HCP cluster templates
5. Make cluster role configurable

Type of change

• Bug fix (non-breaking change that fixes an issue)
• New feature (non-breaking change that adds functionality)
• Breaking change (fix or feature that changes existing behavior)
• Docs / chore / CI only

Checklist

• I have read the CONTRIBUTING guide.
• make test passes locally.
• make lint passes locally.
• make verify passes locally (generated code and formatting are committed).
• I have added/updated tests where appropriate (table-driven, deterministic).
• I have updated docs / manifests where appropriate.

Special notes for reviewers

[AmitSahastra]

@Kun483 These could be blocking issue for clusterctl: --cluster-role is global, not per-cluster

This is the core Palette assumption that breaks. --cluster-role is a single process-wide flag
(main.go:7254/7266) that gates whether HMC (hcp) or VEC (wlc) is registered. In Palette's
self-hosted/pivoted model each cluster runs its own controller, so per-cluster roles work. With
clusterctl there is one CAPMAAS provider instance in the management cluster managing both the HCP and
WLC MaasCluster objects — and it can only be hcp or wlc, never both.

So in a standard single-management-cluster clusterctl setup you cannot get HMC (HCP maintenance) and
VEC (WLC evacuation) simultaneously. The guide's own troubleshooting line ("make sure the controller
for each cluster is started with the correct --cluster-role", HCP_WLC_GUIDE.md:4323) assumes a
topology clusterctl doesn't produce. clusterctl won't install the same provider twice.

Recommendation: register HMC and VEC unconditionally and have each controller filter the objects it
acts on (e.g. HMC acts on MaasCluster with lxdConfig.enabled, VEC on machines with spec.lxd.enabled),
using predicates in SetupWithManager. Keep --cluster-role only as an optional opt-out. That makes
one management cluster serve mixed HCP+WLC fleets — the actual clusterctl shape.

[AmitSahastra]

MAAS credential secret undocumented for clusterctl. Everything reads
capmaas-manager-bootstrap-credentials (keys MAAS_ENDPOINT/MAAS_API_KEY). In Palette the bootstrapper
creates it; with clusterctl the user must create it manually, and the guide never says so. Add a
"create the MAAS credentials secret / set MAAS_ENDPOINT+MAAS_API_KEY" prerequisite step.
(GetMaasClientIdentity also falls back only to MAAS_API_URL/MAAS_API_TOKEN, inconsistent with
GetMAASCredentials which accepts both pairs — worth unifying.)

[Kun483]

MAAS credential secret undocumented for clusterctl. Everything reads capmaas-manager-bootstrap-credentials (keys MAAS_ENDPOINT/MAAS_API_KEY). In Palette the bootstrapper creates it; with clusterctl the user must create it manually, and the guide never says so. Add a "create the MAAS credentials secret / set MAAS_ENDPOINT+MAAS_API_KEY" prerequisite step. (GetMaasClientIdentity also falls back only to MAAS_API_URL/MAAS_API_TOKEN, inconsistent with GetMAASCredentials which accepts both pairs — worth unifying.)

@AmitSahastra , The secret is not something the user creates manually. It ships as part of the provider's infrastructure-components.yaml, sourced from config/default/credentials.yaml. So the real flow is:

1. User sets MAAS_ENDPOINT / MAAS_API_KEY in ~/.cluster-api/clusterctl.yaml (or env).
2. clusterctl init --infrastructure maas substitutes them and creates capmaas-manager-bootstrap-credentials in
   capmaas-system automatically.
3. The controller Deployment pulls those into its env via secretKeyRef (confirmed in the rendered components).