`comfy launch --background` fails with FileNotFoundError when comfy-cli is invoked by path

**Describe the bug**
`background_launch()` re-execs the CLI as a **bare `"comfy"`** through `subprocess.Popen` (no `shell=True`), so the child is resolved via `PATH`. When comfy-cli is invoked by its own path from a virtualenv that hasn't been activated — e.g. `/path/to/.venv/bin/comfy launch --background` — the child spawn raises `FileNotFoundError` and the launch dies with an unhandled traceback.

This is a normal way to use a Python console script (it's how a script or launcher invokes a tool it installed into a project-local venv), and comfy-cli otherwise anchors subprocesses properly — `resolve_python.py` and `uv.py` use `sys.executable` throughout. Only this call site assumes `PATH`.

**To Reproduce**

```sh
python3 -m venv .venv-comfy
.venv-comfy/bin/pip install comfy-cli

# a stand-in workspace is enough to reach the failing call
mkdir -p fake-ws && echo 'print("hi")' > fake-ws/main.py

# the key condition: `comfy` is NOT on PATH
env -i HOME="$HOME" PATH=/usr/bin:/bin \
./.venv-comfy/bin/comfy --skip-prompt --workspace="$PWD/fake-ws" launch --background
```

## Environment

- comfy-cli **1.15.0**
- Python 3.11, Linux (originally hit on macOS / Apple silicon)
- comfy-cli installed into a project-local venv and invoked without activating it

**Observed**

```
FileNotFoundError: [Errno 2] No such file or directory: 'comfy'
```

…raised from `comfy_cli/command/launch.py` → `background_launch` → `subprocess.Popen`.

**Expected behavior**
The background launch should start, as it does when the same binary's directory happens to be on `PATH`. Re-running the identical command with only `PATH="$PWD/.venv-comfy/bin:$PATH"` changed gets past the spawn and executes the workspace — `PATH` is the only variable.

**Cause**

`comfy_cli/command/launch.py`, in `background_launch()`:

```python
cmd = [
"comfy",
f"--workspace={os.path.abspath(os.getcwd())}",
"launch",
]
...
process = subprocess.Popen(
cmd,
stdout=logfh,
stderr=subprocess.STDOUT,
env=env,
)
```

`cmd[0]` is a bare name, so `Popen` resolves it against `PATH` — which need not contain the comfy-cli that is currently running.

## Suggested fix

Anchor the re-exec to the running installation rather than to `PATH`. Either of these is a no-op when `comfy` *is* on `PATH`:

```python
cmd = [sys.argv[0], f"--workspace={...}", "launch"] # the path actually invoked
cmd = [sys.executable, "-m", "comfy_cli", f"--workspace={...}", "launch"] # interpreter-anchored
```

`sys.executable`-based spawning would also match what `resolve_python.py` / `uv.py` already do.

## Secondary note

Because the failure happens *after* the parent prints `Launching ComfyUI from: `, it reads as though ComfyUI itself failed to start, which sends you looking at the workspace and its models rather than at the CLI. Catching `FileNotFoundError` around the spawn and reporting something like *"could not re-exec `comfy`; is it on PATH?"* would make the failure self-explanatory even before the fix above.

**Nice to have**
- [ ] Terminal output
- [ ] Screenshots

**Additional context**
Add any other context about the problem here.

Start in comfy_cli/command/launch.py at background_launch() and inspect how the command passed to subprocess.Popen is built and spawned. Re-run the virtualenv reproduction with comfy absent from PATH, then verify that the same path-invoked CLI can launch in the background without a FileNotFoundError and that the workspace executes.

Written by the indexing model from the issue text.