kubevirt-cdi: make update deletes the first-party uploadproxy templates it never refetches #4028

What happens

make update in packages/system/kubevirt-cdi starts with rm -rf templates and then downloads a single file, templates/cdi-cr.yaml. The directory also holds two templates that Cozystack authored and no fetch ever recreates: cdi-uploadproxy-ingress.yaml and cdi-uploadproxy-tlsroute.yaml (added in d2e851f). Running the target deletes both, and nothing tells you: the recipe exits zero and the tree is one git checkout away from shipping a CDI chart without the upload proxy exposure.

Where it comes from

The recipe treats templates/ as fully vendored, which it was when the package held only the upstream CR. The two local templates arrived later and the recipe never learned about them.

Fix shape

Same one-word change #4015 made in packages/system/kubevirt-operator/Makefile for the same class of loss (that recipe used to remove the local prometheusrule.yaml the same way): replace rm -rf templates and mkdir templates with mkdir -p templates, so the fetch only overwrites the file it downloads.

packages/system/kubevirt-cdi-operator/Makefile has the same rm -rf templates shape, and the same change there would be a regression rather than a fix. Its recipe runs patch and awk -i inplace inside templates/, so the wipe is what clears what those leave behind when they fail: a .rej from a rejected hunk, and a cdi-operator.yaml.gawk.XXXXXX temp when gawk dies abnormally. The reject breaks the render loudly, the gawk temp renders at exit 0 and ships a duplicate object. That was not true when this was written, because those patches ran at -p1 and produced nothing under templates/; #3920 moved them to -p4.

Listing those extensions in the recipe is the wrong shape too, since the list is open. kubevirt-operator on main shows the one that closes the class: download and transform at the package root, where Helm cannot see the intermediate files, and move the finished file in once. Restructuring kubevirt-cdi-operator that way is a change of its own. Until then that package keeps its wipe, and the invariant added alongside this fix is what makes the loss loud rather than silent: it scans that package, so a first-party manifest added there fails the check instead of disappearing.

Found while working on #4015; the CDI packages were outside that change.