fix(kustomize): vendor kured manifest via data.http to avoid github.com release-asset URL bug

[volade]

Why

`kustomize` >=5 mis-detects URLs of the form `https://github.com/{owner}/{repo}/releases/download/.../X.yaml\` as git repository sources, refuses to fetch them as plain files, and fails the post-install hook (`kubectl apply -k /var/post_install`) with:

```
accumulating resources from
'https://github.com/kubereboot/kured/releases/download/X/kured-X-combined.yaml':
URL is a git repository
```

This blocks every `terraform apply` that triggers a `terraform_data.kustomization` recreate (e.g. nodepool changes that mutate helm values, source / module bumps), making downstream cluster work intermittently impossible.

The current `locals.tf::kustomization_backup_yaml` references the kured release asset directly, so any cluster running on a recent k3s ships a `kubectl` whose bundled kustomize trips this case. Hit on a real cluster today.

What

• New `data "http" "kured_manifest"` in `data.tf` that fetches the kured manifest server-side at plan time. `data.http` transparently follows the github.com release-asset 302 redirect to `objects.githubusercontent.com`, returning the YAML body — kustomize never sees the github.com URL.
• Upload the fetched body to `/var/post_install/kured-base.yaml` via a `provisioner "file"` in the `terraform_data.kustomization` resource, alongside the existing kured patch overlay upload.
• Reference it by file name (`"kured-base.yaml"`) from `local.kustomization_backup_yaml.resources` instead of the URL.

The existing `kured.yaml` patch overlay (`local.kured_options` → DaemonSet container args) is unchanged.

Behaviour

• No new variables.
• No change for users: `var.kured_version`, `local.kured_yaml_suffix`, and the `data.http.kured_release` version-discovery lookup all continue to determine which kured version is fetched.
• Same suffix logic respected (`-combined.yaml` for >= 1.20.0, `-dockerhub.yaml` for older).

Diff size

3 files, +28 / -1 lines. Reviewable in a minute.

Follow-up (intentionally out of scope)

The same `https://github.com/.../releases/download/...\` pattern appears for:

• hetzner CCM (`ccm-networks.yaml` when `hetzner_ccm_use_helm = false`)
• rancher `system-upgrade-controller` (`system-upgrade-controller.yaml` and `crd.yaml`)

They could be migrated identically. Left out here to keep this PR minimal and reviewable; happy to open follow-up PRs if this approach is accepted.

Test plan

• Patch applied locally on a fork of master and pushed.
• Verified `data.http.kured_manifest.response_body` returns the kured YAML at plan time (github.com 302 → objects.githubusercontent.com is followed transparently).
• Apply on a fresh cluster and confirm `kubectl apply -k /var/post_install` no longer hits the `URL is a git repository` error.

[gemini-code-assist]

Code Review

This pull request modifies the deployment of kured by fetching its manifest via a Terraform http data source and uploading it as a local file to avoid Kustomize >= 5 mis-detecting GitHub URLs as git repositories. Feedback indicates that the terraform_data resource should include a hash of the manifest content in its triggers_replace block to ensure updates are applied to existing clusters. Furthermore, it is recommended to vendor the system-upgrade-controller manifests as well, as they follow the same URL pattern and may cause similar failures.