Make the scheduler-k3s pair tasks able to declare the whole map

Description of feature

dokku_scheduler_k3s_annotations and dokku_scheduler_k3s_labels are additive. Both delegate to planPairsSet, which computes driftedKeys(desired, current) and emits one command per key that is new or changed. A key stored on the server but absent from the recipe is never visited, so it survives every apply. dokku_scheduler_k3s_autoscaling_auth has the same shape.

dokku/dokku#8990 asks for a whole-set form of scheduler-k3s:annotations:set and scheduler-k3s:labels:set, since both are per-key today. Once that lands, these tasks can grow an authoritative state that declares the complete map.

An interim is available without upstream: passing an empty value to annotations:set deletes that single key, so docket could compute the orphans and delete them one at a time. That is N non-atomic invocations, and a failure partway through leaves the app carrying a mixture of the old and new sets, which is the specific outcome the upstream issue argues against. Whether that is an acceptable stopgap depends on how much we mind a partially-applied annotation map.

When implementing, the state name should match whatever the other authoritative tasks settle on - dokku_domains and dokku_ports use set and clear today, and consistency across the collection-valued tasks matters more than any individual choice.

Blocked on dokku/dokku#8990.

Start with planPairsSet and driftedKeys to understand the current additive behavior for dokku_scheduler_k3s_annotations, dokku_scheduler_k3s_labels, and dokku_scheduler_k3s_autoscaling_auth. Check dokku/dokku#8990 before choosing the authoritative state name or application strategy. Done means the relevant tasks can declare complete collection state consistently with dokku_domains and dokku_ports.