fix(tracing+ollama): split streaming span test into fast mock + slow e2e; add 300s default timeout

[planetf1]

The test was hanging because two things combined badly: `OllamaModelBackend` had no httpx timeout at all, so a stalled stream would park the event loop forever; and the test wasn't marked `slow`, so it ran on every push on a CPU-only runner where after ~30 min the model gets evicted and takes minutes to reload — longer than any safe scalar timeout.

The main fix is moving the test out of standard CI. A new `integration`-marked test does the same structural check against a mocked backend (no Ollama needed, ~200 ms). The original real-model test stays but picks up `@pytest.mark.slow`, so `pyproject.toml`'s `addopts = "-m not slow"` keeps it off standard CI pushes. The 300 s default timeout is a secondary safety net for when the slow test does run.

Test	Markers	What it verifies
`test_streaming_span_creates_and_closes_span` (new)	`integration`	TracingPlugin opens a `chat` span, keeps it open for the full stream, and closes it when done — mocked `AsyncClient.chat` returning a fake async-generator with artificial per-chunk delays
`test_streaming_span_duration` (existing)	`e2e + ollama + slow`	Same invariant against a real Ollama model — belongs on the nightly GPU runner

Why not `httpx.Timeout(connect=30, read=600, ...)`? A structured timeout would let us tune connection setup and read time independently. The trade-off is an explicit `import httpx` in `ollama.py` and a wider type annotation. The scalar is fine for now; a follow-up can add the structured form if we need finer control.

Breaking change: default timeout

`OllamaModelBackend` now defaults to a 300 s timeout (previously unlimited). Users running large models on CPU, very long contexts, or multi-minute generations may hit `httpx.ReadTimeout` where they previously saw the call complete eventually. Pass `timeout=None` to restore the previous unlimited behaviour:

```python
backend = OllamaModelBackend("granite3.1-dense:8b", timeout=None)
```

Tested

Mocked integration test — no Ollama needed, runs in standard CI:

```
uv run pytest test/telemetry/test_streaming_tracing_integration.py -v
```

Passed locally in ~4.75 s. CI: ✅ passes on 3.11, 3.12, 3.13.

Slow e2e test — real Ollama with `granite3.1-dense:8b`, excluded from standard CI via `-m not slow`:

```
uv run pytest test/telemetry/test_tracing_backend.py::test_streaming_span_duration -v -m slow
```

Passed locally in ~6 s against a local Ollama instance. This test is excluded from standard CI pushes and will run in overnight/nightly runs where a GPU-backed Ollama server is available.

Closes #1272

[planetf1]

Closing while we work out the right approach — see the updated diagnosis in #1272.

[akihikokuroda]

LGTM

[planetf1]

thanks @akihikokuroda . I'll wait for @ajbozarth to give it a once-over given interest in otel -- Alex feel free to merge if you are happy with it

[ajbozarth]

I'll be cleaning up streaming spans in #1051 as soon as #1289 is merged, but I have one ask for a file rename in addition to Claudes findings below.

[ajbozarth]

Strategy makes sense — the mocked integration test gives us the structural check in CI without the CPU-only flakiness, and gating the real test behind slow is the right call. A few things to consider inline.

[planetf1]

Thanks @ajbozarth — addressed in the latest commit:

• Widened _check_ollama_server to also catch httpx.TimeoutException and httpx.ConnectError (matching the pattern already used in _pull_ollama_model)
• Tightened the span-duration assertion to >= 0.1 s with a comment tying the threshold to the 3 × 50 ms fake stream
• Updated the PR body to call out the default timeout change and the timeout=None escape hatch for the auto-generated release notes

Happy to leave the file rename to your cleanup in #1051.