datatrove 0.9.0 `VLLMServer` is incompatible with newer vLLM CLI (`--disable-log-requests` removed)

## Summary

`datatrove==0.9.0` currently hardcodes the `--disable-log-requests` flag when starting `vllm serve`.

That flag is no longer accepted by newer vLLM releases such as `vllm==0.19.0`, where request logging is now controlled by the opt-in flag `--enable-log-requests` instead.

As a result, datatrove fails before the inference server starts.

## Environment

- datatrove: `0.9.0`
- vllm: `0.19.0`
- torch: `2.10.0`
- Python: `3.12`
- OS: Linux
- Execution mode: local single-node pipeline through `LocalPipelineExecutor`

## Minimal Reproduction

Install a compatible environment with a recent vLLM:

```bash
pip install \
"datatrove[io]==0.9.0" \
"vllm==0.19.0" \
"transformers>=4.56.0,<5" \
"huggingface-hub>=0.34.0,<1.0"
```

Run a minimal datatrove inference pipeline using `InferenceRunner` with `server_type="vllm"`.

The failure happens when datatrove starts the vLLM server subprocess.

## Actual Behavior

datatrove launches a command equivalent to:

```bash
vllm serve \
--port \
--max-model-len \
--trust-remote-code \
--disable-log-requests \
--disable-uvicorn-access-log \
...
```

With `vllm==0.19.0`, that fails with:

```text
vllm: error: unrecognized arguments: --disable-log-requests
```

The server never becomes ready, and the datatrove pipeline aborts.

## Expected Behavior

datatrove should be able to start `vllm serve` successfully with supported vLLM versions, or fail earlier with a clear compatibility error.

At minimum, `datatrove` should not pass CLI flags that no longer exist in supported vLLM releases.

## Root Cause

The current implementation in `datatrove.pipeline.inference.servers.vllm_server.VLLMServer._start_vllm_task()` unconditionally appends:

```python
"--disable-log-requests"
```

However, in newer vLLM versions, request logging is controlled by `--enable-log-requests`, so the old disable flag is invalid.

In practice, omitting `--disable-log-requests` entirely preserves the intended quiet default behavior on newer vLLM versions.

## Suggested Fix

One of these would solve the problem:

1. Remove `--disable-log-requests` from the command entirely.
2. Detect the installed vLLM version and only pass the flag for versions that still support it.
3. Add an explicit compatibility constraint in `datatrove` so unsupported vLLM versions cannot be installed silently.

The most robust option is probably:

- stop passing `--disable-log-requests`
- keep `--disable-uvicorn-access-log`
- document the tested vLLM version range in the package metadata or README

## Local Workaround

I worked around this by monkey-patching `VLLMServer._start_vllm_task()` to remove `--disable-log-requests` before building the `vllm serve` command.

After that change, datatrove got past this specific startup failure.

## Relevant Log Excerpt

```text
2026-04-09 14:12:26.114 | DEBUG | datatrove.pipeline.inference.servers.vllm_server:_start_vllm_task:91 - Starting VLLM server with command: vllm serve Qwen/Qwen3-14B --port 26806 --max-model-len 16384 --trust-remote-code --disable-log-requests --disable-uvicorn-access-log --revision=main --dtype=bfloat16 --max_num_seqs=256 --max_num_batched_tokens=8192 --block-size=16 --gpu-memory-utilization=0.9 --optimization-level=3 --data-parallel-size=8
2026-04-09 14:12:36.191 | INFO | datatrove.pipeline.inference.servers.vllm_server:process_line:165 - usage: vllm [-h] [-v]
2026-04-09 14:12:36.191 | INFO | datatrove.pipeline.inference.servers.vllm_server:process_line:165 - {chat,complete,serve,launch,bench,collect-env,run-batch} ...
2026-04-09 14:12:36.191 | INFO | datatrove.pipeline.inference.servers.vllm_server:process_line:165 - vllm: error: unrecognized arguments: --disable-log-requests
```

Inspect datatrove.pipeline.inference.servers.vllm_server.VLLMServer._start_vllm_task() and reproduce the startup command with the stated datatrove and vLLM versions. Verify that the server starts without passing the removed --disable-log-requests flag while retaining the other supported options.

Written by the indexing model from the issue text.