[r266-tech]

The client-disconnect cancellation added in #2127/#2131 (issue #2122) left a metrics-accuracy gap.

In api_recall/api_reflect the engine call runs inside with metrics.record_operation(...), and run_cancellable_on_disconnect converts the engine's OperationCancelledError into HTTPException(499). That 499 propagates out through record_operation's blanket except Exception: success = False, so every abandoned/cancelled recall and reflect is counted as a failed operation on the documented hindsight.operation.total success label — inflating the recall/reflect failure rate (and any alerts built on it) the moment a client disconnects. The engine already treats cancellation as "not a failure to retry or report" (OperationCancelledError); record_operation was the one place still violating that.

Fix: recognise a client cancellation in record_operation and exclude it from hindsight.operation.total entirely — it's neither a success nor a failure, so it inflates neither rate, and its partial duration isn't recorded. Cancellation is detected via the exception's __cause__ chain (the HTTP layer raises HTTPException(499) from OperationCancelledError), not a bare status code, so an unrelated 499 is still recorded as a failure.

I kept the binary success label unchanged, so there's no docs/generated-file change. If you'd prefer explicit observability I'm happy to switch to a distinct cancelled outcome instead (that would also update monitoring.md + regenerate the skills docs mirror) — let me know which you'd rather have.

Regression tests cover: a direct OperationCancelledError and the HTTPException(499) from cancel path are excluded from the counter/histogram, while a bare 499 (no cancellation cause) is still recorded as a failure.