Native Windows support for Omnigent, specifically addressing POSIX assumptions.

I tested the documented `uv` path on native Windows and still hit import-time POSIX assumptions.

Commands:

```powershell
uv --version
uv run omnigent --help
```

`uv` is installed and working, but `uv run omnigent --help` fails before the CLI loads:

```text
AttributeError: module 'signal' has no attribute 'SIGUSR1'
```

The failing line appears to be:

```python
RUNNER_ADOPT_SIGNAL = signal.SIGUSR1
```

in `omnigent/runner/identity.py`.

I also checked the SDK tool import path. After temporarily bypassing the `SIGUSR1` failure, it reaches another native Windows blocker:

```text
ModuleNotFoundError: No module named 'fcntl'
```

from `sdks/python-client/omnigent_client/tools/_state.py`.

WSL2 does work for these specific blockers: `SIGUSR1` exists there, `fcntl` imports, and `python -m omnigent --help` prints the CLI help after installing in a WSL venv.

Would native Windows support be welcome as a contribution, or is the intended support target macOS/Linux/WSL2 only for now?

If native Windows is in scope, I would be interested in taking a first pass at a small PR to add guards/fallbacks for these import-time crashes. If not, I can open a docs PR clarifying that Windows users should use WSL2.