v0.14.0

P1 #5: ProviderConfig get/update + image/network discovery (butleradm)

The butleradm provider group gains four verbs, closing audit P1 #5 so a CLI-only operator can run the full cluster-create workflow without falling back to the console.

butleradm provider get NAME [-n ns] [-o json|yaml]
butleradm provider update NAME --from-file f.yaml [-n ns]
butleradm provider images NAME [-n ns] [-o table|json|yaml]
butleradm provider networks NAME [-n ns] [-o table|json|yaml]

Verb	Mechanism	What it does
get	CRD-direct	Show a ProviderConfig as a detail table, or the full object with -o json/yaml
update	CRD-direct	Update the spec from a YAML file, preserving the existing status and resourceVersion
images	butler-server	List the images a provider can use, for finding the image ID cluster create needs
networks	butler-server	List the networks a provider can use

get and update are CRD-direct

Both read and write the ProviderConfig directly, like the rest of the provider group. update does Get-then-merge-spec-then-Update and applies only the spec, so the existing validation status and resourceVersion are preserved. A spec edit never clobbers status.

images and networks are policy-filtered

Discovery goes through butler-server so the list is filtered by the same image and network policy the console applies. CLI and console show the same allowed options from one source of truth.

Discovery is supported for the on-premises providers (harvester, nutanix). For cloud providers (aws, azure, gcp) and proxmox the image and network are set directly as fields on the ProviderConfig (for example awsVpcId, gcpImage, azureImageUrn), so those return a clear message naming the provider and pointing at the config fields rather than an error dump.

Validation

Both load-bearing paths are covered by tests: the update merge that preserves status and resourceVersion, and the friendly message for the on-premises-only discovery boundary.