make sync fails on Python 3.14: the locked cffi 1.17.1 has no cp314 wheel, so the dev group needs a C compiler

`pyproject.toml` advertises Python 3.14 (`Programming Language :: Python :: 3.14`, line 26) and sets no upper bound on `requires-python`. On 3.14 the documented contributor setup does not complete.

## What happens

From a clean checkout on Windows 11 with Python 3.14.7:

```
$ uv sync            # also fails as `uv sync --all-extras`, and as `make sync`
...
error: Failed to build `cffi==1.17.1`
  ... Microsoft Visual C++ 14.0 or greater is required. Get it with "Microsoft C++ Build Tools"

hint: `cffi` (v1.17.1) was included because `openai-agents:dev` (v0.21.0)
      depends on `sounddevice` (v0.5.2) which depends on `cffi`
```

`uv sync --python 3.12` succeeds immediately on the same checkout, which isolates it to the interpreter version rather than the machine.

## Why

`uv.lock` pins `cffi==1.17.1`. That release publishes wheels for **cp38–cp313 only**:

```
cffi 1.17.1 wheel python tags: cp38, cp39, cp310, cp311, cp312, cp313
cp314 wheel present: False
latest cffi on PyPI:  2.1.1
```

So on 3.14 there is no wheel to install and uv falls back to building from the sdist, which needs a working C toolchain. On Windows that is MSVC Build Tools, which a contributor setting up a Python SDK has no other reason to have. `cffi` reaches the graph only through `sounddevice`, which is pulled by the `dev` group — so it is a hard requirement of the documented setup even for someone who will never touch the voice code.

Linux and macOS contributors on 3.14 are likely to hit the same resolution and survive it, because a C compiler is usually already present. The failure is therefore Windows-visible but not Windows-caused.

## Why it is worth fixing rather than documenting

`AGENTS.md` tells a contributor to run `make sync` as step 3 of repo setup, and `requires-python` plus the 3.14 classifier tell them 3.14 is a supported interpreter. Someone who installs the newest stable Python — the reasonable default — hits a compiler error naming `cffi`, a package they did not ask for, in service of `sounddevice`, which they also did not ask for. Nothing in the error points back at the voice extra or suggests using an older interpreter.

## Possible directions

Not proposing one, since the dependency policy is yours:

1. Refresh the `cffi` pin in `uv.lock`. 2.1.1 publishes cp314 wheels.
2. Move `sounddevice` out of `dev` and into the `voice` extra only, so the base contributor setup does not pull an audio stack.
3. Cap `requires-python` (or drop the 3.14 classifier) until the dev graph installs cleanly on it, so the advertised support matches what setup does.

1 is the smallest and probably sufficient on its own. 2 is the one that stops this class of failure recurring, since it takes the whole native-audio dependency off the default contributor path.

## Environment

Windows 11, Python 3.14.7 (uv-managed), uv 0.12.3, clean clone of `main` at 9aba9002. Reproduces on `uv sync`, `uv sync --all-extras`, and `make sync`. `uv sync --python 3.12` succeeds.

[]