[Bug]: `container builder start --cpus/--memory` do not size the build sandbox; `builder status` reports them anyway

### I have done the following

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

### Steps to reproduce

`container builder start --cpus N --memory M` is reflected in `container builder status`, but
the build sandbox is sized from the `[build]` section of `config.toml` instead. The flags have
no effect on builds.

```bash
mkdir -p /tmp/memprobe && cd /tmp/memprobe
cat > Dockerfile <<'EOF'
FROM alpine:3.20
RUN grep MemTotal /proc/meminfo; nproc
EOF
```

**Case 1 — flags only, no `config.toml` (defaults `cpus = 2`, `memory = "2048mb"`)**

```console
% container system property list | sed -n '/\[build\]/,/^$/p'
[build]
cpus = 2
memory = "2048mb"
...
% container builder delete --force && container builder start --cpus 6 --memory 12G
% container builder status
buildkit ...builder:0.13.1 running 192.168.66.2/24 6 12288 MB <-- as requested
% container build --no-cache -t memprobe:flags .
#5 0.038 MemTotal: 2163972 kB <-- 2 GB, not 12 GB
```

**Case 2 — the discriminating case: `config.toml` says 3 GB, flags ask for 12 GB**

```console
% printf '[build]\ncpus = 3\nmemory = "3gb"\n' > ~/.config/container/config.toml
% container system stop && container system start
% container builder delete --force && container builder start --cpus 6 --memory 12G
% container builder status
buildkit ...builder:0.13.1 running 192.168.66.2/24 6 12288 MB <-- flags echoed
% container build --no-cache -t memprobe:cfg .
#5 0.037 MemTotal: 3131876 kB <-- 3 GB: config.toml won
#5 0.037 4
```

`config.toml` wins over the flags, and `builder status` reports the flag values in both cases.

Note that clearing `~/.config/container/config.toml` alone does not reset this — the values
persist in the read-only copy at
`~/Library/Application Support/com.apple.container/config/config.toml`, which must also be
removed (it is mode `0444`) before `container system start` falls back to the defaults.

### Problem description

The `--cpus` / `--memory` flags on `container builder start` do not size the build sandbox;
only `config.toml` `[build]` does. Because `container builder status` echoes the requested
values either way, there is no CLI-visible signal that the flags were ignored — the only
symptom is a build behaving as if it has the default 2 GB.

This is awkward to diagnose in practice. A Node/TypeScript build sizes its heap from the
sandbox's `MemTotal`, so under the 2 GB default it caps at ~1105 MB and dies with
`FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory` (exit
code 134). Raising the builder with the flags changes nothing; the same request via
`config.toml` raises the heap limit to ~2096 MB and the build completes. Reaching for the
documented flag first, seeing `builder status` agree with it, and still getting the OOM is a
fairly convincing dead end.

I also saw `container builder status` revert from a flag-requested `6 / 12288 MB` back to
`2 / 2048 MB` on its own between builds, with no intervening `builder start` or `stop`.

Expected: either the flags size the build sandbox as `--help` implies, or
`container builder start` warns/errors on flags it will not apply and `builder status` reports
the values actually in effect rather than the ones requested.

### Environment

- OS: macOS 26.5.2 (25F84), Apple M4 Pro, 48 GB, 14 cores
- Container: `container` CLI version 1.3.0 (build: release), apiserver 1.3.0
- Builder shim: `ghcr.io/apple/container-builder-shim/builder:0.13.1`
- Xcode: N/A (Homebrew release binary)

### Code of Conduct

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

Start by tracing how `container builder start --cpus/--memory` parses and stores its options, then compare that path with the `[build]` settings loaded from `config.toml` and the values shown by `container builder status`. Reproduce the two cases in the issue and check existing tests for builder start, config handling, and status. Done means the flags size the build sandbox or the CLI reports that they are not applied and shows the effective values.

Written by the indexing model from the issue text.