Cancelled client requests can leave stale in-flight state #30

Client request tracking is registered before the send and wait complete, but cancellation and send failures do not remove the registered state. SubmitAsync enqueues a JobHandle before sending and leaves it in _pendingSubmits if SendAsync or handle.Accepted.WaitAsync fails, so a later job.accepted can be assigned to the stale handle. ListJobsAsync leaves entries in _listJobsRequests when the wait is cancelled, and SubscribeAsync leaves _subscriptions[jobId] populated if the send or acknowledgement wait fails.

The relevant locations are src/Arcp.Client/ArcpClient.Jobs.cs:17, src/Arcp.Client/ArcpClient.Jobs.cs:18, src/Arcp.Client/ArcpClient.Jobs.cs:53, src/Arcp.Client/ArcpClient.Jobs.cs:54, src/Arcp.Client/ArcpClient.Subscriptions.cs:15, and src/Arcp.Client/ArcpClient.Subscriptions.cs:16.

Fix prompt: Make client-side request registration exception-safe. For submits, either correlate accepted responses by an explicit request id or remove the pending handle when sending or waiting for acceptance fails; if FIFO correlation remains, protect it with cleanup that cannot misroute the next acceptance. For list jobs and subscriptions, remove the dictionary entry in a catch or finally when the operation does not complete successfully. Add tests with a transport that throws on send and tests that cancel the wait before an acknowledgement, then verify the internal tracking collection does not retain stale entries and subsequent successful requests complete normally.