`kars up` removes all pre-existing tags from the target resource group

### Summary

When `kars up` targets an existing resource group, it strips every tag from that group. Tags applied before the run are gone afterwards.

### Version

`@kars-runtime/cli@0.1.26`

### Reproduction

```bash
az group create -n -l \
--tags owner=someone environment=poc expiry=2026-11-30 cost-center=1234

az group show -n --query tags # 4 tags

npx @kars-runtime/cli@0.1.26 up --resource-group ... --yes

az group show -n --query tags # empty
```

Observed on every run, including runs that later failed for unrelated reasons — so the stripping happens early, around the step that logs `Resource group '' ready`.

### Impact

- **Cost attribution breaks.** Tag-based cost allocation in Azure Cost Management silently stops working for the group.
- **Governance tooling breaks.** Policies and automation keyed on tags such as owner, expiry, environment or data-classification stop matching.
- **Safety tooling can break closed.** Teardown guards that assert an expected tag before permitting destructive operations will refuse to run after a deploy, which is the safe direction but still a surprise.

Azure resource-group tag updates are last-write-wins on a full replace, so a `PUT` that omits existing tags removes them. A merge (`az group update --set tags.x=y`, or the ARM equivalent) preserves them.

### Suggested fix

When the resource group already exists, either leave its tags untouched or merge kars's own tags into the existing set rather than replacing it. If replacement is intentional, it should be documented and ideally opt-in.

Start by tracing the `kars up` resource-group creation or readiness path around the log `Resource group '' ready`; the payload does not name a source file or test. Reproduce with `az group create`, inspect tags before and after `kars up`, and confirm that pre-existing tags remain after the fix, including when a later step fails.

Written by the indexing model from the issue text.