zypper Install fails on vendor-change (from mirantis/launchpad)

### Summary

`PackageManager.Install` on zypper (SLES/openSUSE) runs `zypper install -y` **without** `--allow-vendor-change`. As a result, installing **any** package whose only dependency-resolution solution replaces a package provided by a *different vendor* fails non-interactively: zypper presents the vendor-change solution, defaults to *cancel*, and exits 4. The install appears to fail for no clear reason.

This is a general rig behaviour, independent of what is being installed or which tool is driving rig — it affects any consumer whose install set obsoletes/replaces a distro-provided package from another vendor.

### Mechanism

zypper, by default, will not switch a package's vendor during an install/upgrade unless explicitly told to. Interactively it prompts; non-interactively (`-y`/`--non-interactive`) it does not silently accept the vendor-changing solution — it cancels. rig always runs the non-interactive form, so the operation dead-ends with exit 4 and no actionable error.

### Concrete example

One easy way to hit this: a stock SLES 15 SP7 cloud image (e.g. AWS `suse-sles-15-sp7-*`) ships SUSE's own `containerd` package pre-installed. Installing a third-party container-runtime package that *obsoletes* it (any vendor's `containerd.io`-style package from an add-on repo — Docker/Mirantis packages are one such case, but the vendor is irrelevant to the mechanism) triggers exactly this:

```go
pm, _ := client.Sudo().PackageManager()
err := pm.Install(ctx, "containerd.io") // third-party repo already added
```

runs `zypper install -y containerd.io`, which resolves only to a vendor-change:

```
Problem: 1: the to be installed containerd.io-...x86_64 requires 'containerd.io-runc = ...',
but this requirement cannot be provided
Solution 1: install containerd.io-minimal-... from vendor
replacing containerd-1.7.29-...x86_64 from vendor SUSE LLC
Solution 2: do not install containerd.io-...
Solution 3: break containerd.io-... by ignoring some of its dependencies
Choose from above solutions by number or cancel [1/2/3/c/d/?] (c): c # <- non-interactive default
```

Exit code 4, nothing installed. Re-running the same install with `--allow-vendor-change` succeeds (exit 0). This is not specific to any particular package, repo, or vendor — it is the general zypper vendor-change policy meeting rig's non-interactive install.

### Why it matters

- Affects any rig-driven install on SLES/openSUSE where the resolver must cross a vendor boundary (common on cloud images that pre-install distro versions of tools an operator then wants to replace with an upstream/enterprise build).
- The failure is opaque: the exit-4 "cancel" gives no signal that a vendor change was the actual blocker.

### Proposal / open question

Simplest fix: pass `--allow-vendor-change` on the zypper install action (draft PR attached).

**This is deliberately aggressive about package adoption and may be undesirable as a global default** — it lets zypper switch a package's vendor/origin on *any* install, weakening the same-vendor guarantee zypper gives out of the box. Open question for maintainers: is the unconditional flag acceptable, or would you rather gate it behind an **opt-in install option** (which means extending the `PackageManager.Install` signature/interface, a larger change affecting all managers and callers)? Happy to reshape the PR either way.

Written by AI: claude-sonnet-5

Start at the zypper implementation of PackageManager.Install and inspect how it constructs the non-interactive install command. Reproduce the SLES/openSUSE vendor-change case, then confirm the chosen policy either permits the install or provides an opt-in path without breaking other package managers.

Written by the indexing model from the issue text.