[Feature] Allow the background log path to be specified

## What

`comfy launch --background` writes ComfyUI's output to
`/user/comfyui_.log`, and there is currently no way to ask for a
different path. A `--log-file` option on `launch`, or an env var honoured by
`background_log_path()`, would let a supervising process keep that log wherever it
keeps its others.

## Why

comfy-cli is increasingly something *else* starts — a project launcher, a dev
script, a systemd unit. Those supervisors usually have one convention for where
their managed services log (`/tmp/.log`, `/var/log//`, a run
directory), and ComfyUI is the one participant whose log lands somewhere else, in
a location that also moves with the workspace.

In our case (a launcher that starts piper / ollama / a Chatterbox bridge / ComfyUI
side by side) every other helper announces `(logs: /tmp/.log)` on startup
and points back there on failure. ComfyUI can't, so we symlink `/tmp/comfyui.log`
at comfy-cli's file instead. That works fine — this is a convenience request, not
a defect report.

## Current state, for reference

- `launch` exposes `--background` and `--frontend-pr`; no log option.
- `background_launch()` computes `log_path = background_log_path(port)`
unconditionally.
- The `background_log` config key looks like it might be an input, but it's
written *by* comfy-cli after launch and read back only by `comfy logs` to locate
the file.

## Suggested shape

Either is fine; the env var alone would cover the supervisor case:

```python
def background_log_path(port, workspace: str | None = None) -> str:
override = os.environ.get("COMFY_BACKGROUND_LOG")
if override:
return os.path.abspath(override)
...
```

## One thing worth preserving

`_open_log_for_write()` opens with `O_NOFOLLOW` so a pre-placed symlink in
`/user` can't be used to clobber its target — a good defence, and an
override path should keep it rather than special-casing "trusted" locations. Worth
saying explicitly in the docs for such an option: **the override must be a real
file path, not a symlink**, or the launch fails with `ELOOP`.

That behaviour is also why the workaround has to point the other way (a symlink
*at* comfy-cli's file, never the workspace path symlinked outward) — which is
easy to get backwards, and might deserve a line in the `comfy logs` docs
regardless of whether this request is taken up.

Start with the launch entry point and trace background_launch() into background_log_path(port); inspect _open_log_for_write() and how comfy logs reads the background_log config key. Decide whether the environment variable or a launch option is the supported interface, then verify the selected path is recorded and the existing no-follow-symlink protection remains intact. Update the relevant comfy logs documentation if the behavior changes.

Written by the indexing model from the issue text.