[Bug]: leftover /etc/resolver/containerization.* 'search' directive hangs ALL bare-hostname DNS lookups system-wide once apiserver stops

### I have done the following

- [x] I have searched the existing issues
- [x] If possible, I've reproduced the issue using the 'main' branch of this project

### Steps to reproduce

1. Follow the container DNS tutorial, e.g. `sudo container system dns create test`, then run a container and resolve it via `.test` (see `/etc/resolver/containerization.test` created as described in #1407).
2. Stop the container system entirely: `container system stop` (or just let the apiserver not be running, e.g. after a reboot before starting it again).
3. Do **not** remove `/etc/resolver/containerization.test` — it is left in place.
4. From the host, resolve *any* bare, unqualified hostname unrelated to containers at all, e.g. one handled by a VPN's split-DNS (in my case a Tailscale MagicDNS short name), or any LAN hostname:
```
time dscacheutil -q host -a name some-other-host
```

### Problem description

`/etc/resolver/containerization.test` (created by the DNS tutorial / `container system dns create`) contains:

```
domain test
search test
nameserver 127.0.0.1
port 2053
```

The `search test` directive adds `test` to **macOS's system-wide search-domain list** — the list used to expand *any* unqualified single-label hostname, not just ones ending in `.test`. This is independent of the `containerization.test` filename-vs-`domain` mismatch already reported in #1407.

The practical effect: once the container apiserver is not running (stopped, or simply not yet started after boot), `127.0.0.1:2053` has nothing listening. Every bare hostname lookup on the Mac — SSH to a Tailscale MagicDNS short name, a LAN device, anything with no dot in it — now also gets tried as `.test` against that dead nameserver as part of normal search-domain expansion, and that query hangs (no ICMP unreachable, no fast refusal) rather than failing quickly. Observed delay: consistently ~10 seconds per bare-hostname lookup, which is enough to make unrelated tools (ssh, ping, etc.) appear to hang system-wide.

This makes the resolver file dangerous to leave behind: the "harmless" tutorial artifact silently degrades unrelated DNS resolution for the entire machine as soon as the container apiserver stops, until the file is manually deleted (`sudo rm /etc/resolver/containerization.test`) and there's no message/warning to that effect.

### Expected behavior

Either:
- `container system dns create ` should not use a global `search` directive at all — `/etc/resolver` files should only need `domain`/`nameserver`/`port` to scope matching by filename per `resolver(5)`, without contributing to the system-wide search list, or
- The resolver file (and its `search` contamination) should be automatically removed when `container system stop` runs / the apiserver is not registered with launchd, or
- At minimum, `container system status` / `container system stop` should warn if a stale `/etc/resolver/*` file exists pointing at a now-unreachable local port, since its side effects extend well beyond container networking.

### Environment

```markdown
- OS: macOS 26.5.2
- Container: 1.1.0
```

### Code of Conduct

- [x] I agree to follow this project's Code of Conduct

Start by reviewing the implementation behind `container system dns create` and `container system stop`, the `/etc/resolver/containerization.*` files, and the DNS tutorial referenced in #1407. Reproduce the stale resolver scenario, then verify that stopping the system no longer leaves a global `search` side effect, or clearly warns or removes the stale resolver configuration.

Written by the indexing model from the issue text.