Allow user to specify bootstrapper version in recipe

### Checklist

- [x] I added a descriptive title
- [x] I searched open requests and couldn't find a duplicate

### What is the idea?

Add a `bootstrapper` field (name TBD) to `construct.yaml` that allows specifying a MatchSpec for `conda-standalone`. Then `constructor` would solve this spec against the recipe's `channels`, download the package, extract the binary, and use it for the build.

As a dummy example:

```yaml
name: MyInstaller
version: "1.0"
channels:
- conda-forge
bootstrapper: conda-standalone>=24.9,<25
specs:
- python=3.11
```

### Why is this needed?

Currently, the `conda-standalone` version bundled in installers is opaque:

1. It's determined by what's installed in the build environment or passed via `--conda-exe`
2. After an installer is built, there's no practical way to determine which version was used
3. This makes reproducing older installers difficult or impossible

A potential pain point users can run into is **GLIBC compatibility** - newer `conda-standalone` builds may require higher GLIBC versions, breaking installers on older Linux systems. Without knowing which version was originally used, users cannot rebuild compatible installers.

### What should happen?

1. User adds `bootstrapper: conda-standalone>=24.9,<25` to their `construct.yaml`
2. Constructor solves this spec against the recipe's `channels`
3. Constructor downloads and extracts the matching `conda-standalone` package
4. The extracted binary is used for the build (same as if passed via `--conda-exe`)
5. The resolved version is recorded in build metadata

When `bootstrapper` is not specified, current behavior is preserved (use `--conda-exe` or the default from the build environment); backwards compatibility.

### Additional Context

**Open questions for discussion:**

- **Field naming:** `bootstrapper` vs `conda_standalone_spec` vs `conda_exe_spec`
- **Precedence:** How does this interact with `--conda-exe` CLI argument and the default `sys.prefix/standalone_conda/conda.exe`?
- **Micromamba support:** Should this also support `micromamba` as an alternative?
- **Error handling:** Hard-fail or fallback if the spec cannot be satisfied?

There are likely more but just for the sake of bookkeeping.

Start with the recipe's construct.yaml field and trace how --conda-exe and the default sys.prefix/standalone_conda/conda.exe are selected. Clarify the field name, precedence, error handling, and whether micromamba is included before implementing resolution against the recipe channels. Done means the requested conda-standalone version is downloaded, extracted, used for the build, recorded in metadata, and omitted fields preserve current behavior.

Written by the indexing model from the issue text.