fix(loop): drive compaction from full request counts

README.md

@@ -65,6 +65,24 @@ The existing `orchestrator:provider_budget` event exposes each preflight's
 attempt, result, estimate, allowance, and requested context budget to mounted
 observability consumers.
 
+### Provider-count measured compaction
+
+When both sides advertise the optional measured contracts —
+`context.measured_request_view` and
+`request_budget:provider_count` — the loop lets Context compact against the
+provider's native input count. Context returns the exact `ChatRequest` it
+counted, and the loop sends that same object after committing the selected
+retention transaction. This path is additive: contexts and providers without
+both capabilities keep the legacy request-budget preflight and estimate-based
+retention behavior.
+
+For non-streaming foreground responses, the optional
+`context.foreground_usage` capability records only normalized successful
+response usage. A counted streaming request records its selected provider count.
+If a pre-chunk overflow requires a stream retry, that reading is marked stale
+rather than attributed to the replacement request. Streams without a provider
+count do not invent usage; an already-owned reading is marked stale.
+
 ### Provider-reported overflow recovery
 
 A provider may optionally expose synchronous `recover_context_overflow` to