[verified] fix: preserve tracker precision eligibility

.scratch/proxy-stream-cancellation/PRD.md

@@ -0,0 +1,27 @@
+# PRD: Streaming proxy cancellation delivery
+
+## Overview
+
+A tracker proxy route can be selected and registered as active, but a direct SSE upstream may not deliver its first frame to the downstream client until the upstream response completes. A dashboard cancellation request made after the upstream emitted and flushed an SSE frame can therefore arrive after the tracker has already finalized and unregistered the proxy, returning 404.
+
+## Goal
+
+Preserve immediate SSE frame delivery and keep the active-proxy record cancelable until the streaming response actually completes or is canceled.
+
+## Quality gates
+
+- Run the focused tracker streaming/cancellation tests.
+- Run full `python -m pytest -q` and record unrelated failures exactly.
+- Do not weaken billing, disconnect handling, proxy-inflight accounting, or cancel authorization.
+
+## User story
+
+### PSC-001: Cancel an active direct SSE proxy
+
+As a dashboard operator, I need a cancellation request to reach an active direct SSE proxy after its first streamed frame, so I can stop long-running inference without a race-induced 404.
+
+## Non-goals
+
+- Do not change route selection or quantization policy.
+- Do not alter relay transport behavior unless needed to share the same cancellation invariant.
+- Do not introduce client-visible buffering.

.scratch/proxy-stream-cancellation/issues/01-direct-sse-cancellation-race.md

@@ -0,0 +1,34 @@
+# 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.