# PSC-001 — Direct SSE cancellation race

Status: ready-for-agent
Priority: High

## Problem

`tests/test_tracker_routing.py::test_tracker_dashboard_can_cancel_inflight_proxy` registers a streaming upstream node. The upstream writes and flushes the first SSE frame, then waits three seconds. The tracker’s client does not receive that frame until after the upstream has completed; by then `_unregister_active_proxy()` has run and the dashboard cancellation endpoint returns 404.

Observed trace:

```text
proxy route selected
proxy connected
proxy progress ... elapsed_seconds≈3
proxy complete ... elapsed_seconds≈3
POST /v1/proxy/requests/<id>/cancel → 404
```

This is a production cancellation/delivery race, not a stale test: the endpoint promises to cancel active proxy work, and the upstream had already emitted a first stream frame before cancellation was attempted.

## Acceptance criteria

- [ ] A direct SSE upstream frame is relayed and flushed to the client before the upstream completes.
- [ ] After that first frame, `/v1/proxy/requests/{request_id}/cancel` returns 200 while the stream is active.
- [ ] Cancellation closes/stops the upstream safely, finalizes inflight accounting exactly once, and records the cancellation event.
- [ ] Cancel authorization remains unchanged.
- [ ] Client disconnect and normal SSE completion retain current billing/throughput behavior.
- [ ] Regression test is deterministic and does not rely on timing races longer than necessary.
- [ ] Focused tracker routing tests and full pytest are run with unrelated failures documented.

## Likely seam

Inspect direct streaming behavior around `_handle_proxy_chat` upstream reads (`packages/tracker/meshnet_tracker/server.py`, roughly lines 3953–4019). The direct response path writes/flushed each line, but current HTTP response buffering/reading prevents the line from being observed until stream end. Fix delivery at the proxy transport boundary; do not paper over it by retaining completed proxy records indefinitely.