refactor: make the C# API properly async end-to-end

[hahn-kev]

This should help us to avoid running out of threads, it also gives us cooperative cancellation, this should keep us from running work when the client aborts or cancels it's request.

---

🤖 AI summary

The C# API was a faithful, behavior-preserving rewrite of the PHP app in which only the HTTP entry layer (RestDispatcher) was async — everything below it ran synchronously and blocked request threads. Most notably, two Thread.Sleep poll loops sat on the request thread (up to 14s on the pull path, 5s on validate/unbundle), plus sync-over-async process execution and synchronous large-file streaming. This converts the whole request-handling chain to be async from top to bottom.

Changes (bottom-up):

• ProcessRunner — RunSync → RunAsync using WaitForExitAsync; removed the .GetAwaiter().GetResult() sync-over-async.
• AsyncRunner — WaitForIsComplete → WaitForIsCompleteAsync (Thread.Sleep → Task.Delay); async lock-file read/writes. The static-registry background-task design is intentionally kept (it already survives the originating request); its background write deliberately stays on CancellationToken.None.
• HgRunner — revision/branch/validate/bundle methods are now async Task with a CancellationToken; pure launch methods stayed synchronous.
• HgResumeApi — all endpoints are async Task<HgResumeResponse>; the 7×2s pull Thread.Sleep loop and the validate loop become await Task.Delay; bundle-file streaming is async (GetChunkAsync + async append-write).
• RestDispatcher — Dispatch → DispatchAsync; HttpContext.RequestAborted is threaded end-to-end through body read, dispatch, and response write.

Best-practice details: OperationCanceledException from a client disconnect is caught-and-rethrown before the broad catch blocks so a disconnect can't be mapped to a bogus FAIL/RESET or corrupt the resumable transaction state. Async FileStreams use FileOptions.Asynchronous. No ConfigureAwait(false) was sprinkled into app code (unnecessary in ASP.NET Core). Per scope, the tiny (<1KB) per-transaction metadata JSON I/O was intentionally left synchronous, and no DI was introduced.

Behavior is preserved: the X-HgR-* wire contract, explicit Content-Length, status-code mapping, and the client-visible poll timing (5×1s / 7×2s) are all unchanged — only the blocking mechanism differs.

Test plan

• dotnet build HgResume.slnx — clean, 0 warnings / 0 errors.
• Grep confirms no Thread.Sleep, sync WaitForExit(), or .GetAwaiter().GetResult() remain in src/ (the residual .Result reads are post-await Task.WhenAll, i.e. non-blocking).
• All 48 HgResume.HttpTests pass against the podman container (push/pull resume flows, InProgress polling via the now-Task.Delay loop, unrelated-repo detection, offset/SOW handling, and the manyRevsHgRepo IsValidBase pagination cases).

---

This change is 

[megahirt]

This is a beautiful example of using AI to squash some tech debt - well done!

[hahn-kev]

Yeah it's pretty sweet. I'm hoping next to point a profiler at the full stack and see if we can make it super fast.