Windows shortcuts can silently omit CONDA_PREFIX / env config vars from the activation script

### Checklist

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

### What happened?

**Component:** `menuinst/platforms/win.py`, `WindowsMenuItem._command()` (the `.env`-file branch used for conda >= 25.3.0)

### Summary

When a package's post-install hook calls `menuinst.api.install()` from *inside* the environment it's creating a shortcut for (i.e. `CONDA_SHLVL`/`CONDA_PREFIX`/`CONDA_DEFAULT_ENV` already point at that same target prefix), the generated `.bat` shortcut is missing `CONDA_PREFIX`, `CONDA_DEFAULT_ENV`, and any custom variables set via `conda env config vars set` (from `conda-meta/state`). `PATH` and the `activate.d`/`deactivate.d` hook calls are present and correct, so the shortcut looks activated but isn't fully.

### Root cause

`_command()` shells out to `conda shell.cmd.exe activate ` via `logged_run(activator_cmd, check=True, log=False)` with no explicit `env=`, so the subprocess inherits the calling process's environment as-is. `conda`'s activator only emits `SET` lines for variables whose value differs from what's already in that inherited environment. If the builder process is already activated in the same target env, `CONDA_PREFIX`/`CONDA_DEFAULT_ENV`/config vars already match the target exactly, so conda considers them "unchanged" and omits them — even though the resulting script is meant to run standalone, later, in a fresh `cmd.exe` with none of that ambient state.

### Reproduction

1. Env `myenv` has a custom var set: `conda env config vars set FOO=bar -n myenv`.
2. From a **clean** shell: `conda shell.cmd.exe activate ` → resulting `.env` file includes `CONDA_PREFIX`, `CONDA_DEFAULT_ENV`, and `FOO=bar`.
3. From a shell where `myenv` is **already active** (`conda activate myenv` first): re-run the same `shell.cmd.exe activate ` call → the `.env` file now omits `CONDA_PREFIX`, `CONDA_DEFAULT_ENV`, and `FOO` entirely, while still including `PATH`, `CONDA_SHLVL`, and the `activate.d`/`deactivate.d` `_CONDA_SCRIPT` lines.
4. Since `menuinst`'s post-install-triggered shortcut generation typically requires being run activated (to know `CONDA_PREFIX` in the first place), any package following that pattern gets a shortcut baked from case 3, not case 2.

### Expected

The generated shortcut should be self-contained and always include the full activation state (`CONDA_PREFIX`, `CONDA_DEFAULT_ENV`, and all `conda-meta/state` `env_vars`), regardless of the activation state of the process that built it.

### Suggested fix

In `_command()`, pass a sanitized `env=` to the `logged_run(activator_cmd, ...)` call that strips `CONDA_SHLVL`, `CONDA_PREFIX`, `CONDA_DEFAULT_ENV`, `CONDA_PROMPT_MODIFIER`, `_CE_M`, `_CE_CONDA` before invoking `conda shell.cmd.exe activate`, so the subprocess always computes activation "from scratch" instead of diffing against whatever state the builder process happens to be in.

### Environment

- conda: >= 25.3.0 (uses the `.env`-file activation path in `win.py`, not the older `.bat` path)
- OS: Windows

### Conda Info

```shell

```

### Conda Config

```shell

```

### Conda list

```shell

```

### Additional Context

_No response_

Start in menuinst/platforms/win.py at WindowsMenuItem._command() and inspect the .env-file branch and its logged_run() activation call. Reproduce shortcut generation from a clean shell and from an already activated target environment, then verify the generated .env consistently includes CONDA_PREFIX, CONDA_DEFAULT_ENV, and configured environment variables.

Written by the indexing model from the issue text.