Manual completion client's recordHeartbeat swallows cancellation, reset and pause exceptions

[dssysolyatin]

Expected Behavior

ManualActivityCompletionClient.recordHeartbeat should throw ActivityCanceledException,
ActivityResetException or ActivityPausedException when the server reports cancellation, reset or
pause. The method already builds those exceptions.

The declaration on the public interface should change too. recordHeartbeat is declared
throws CanceledFailure, a type the method never throws. It should name what callers really have to
handle:

// io.temporal.activity.ManualActivityCompletionClient
void recordHeartbeat(@Nullable Object details) throws ActivityCompletionException;

Actual Behavior

ActivityCanceledException, ActivityResetException and ActivityPausedException never reach the
caller. The try block wraps the response checks along with the RPC, so catch (Exception e) catches
all three. processException then turns each one into ActivityCompletionFailureException.

// ManualActivityCompletionClientImpl.java, same on main as of d310594f
try {
  RecordActivityTaskHeartbeatResponse status = ActivityClientHelper.sendHeartbeatRequest(...);
  if (status.getCancelRequested()) {
    throw new ActivityCanceledException();   // caught below, never reaches the caller
  } else if (status.getActivityReset()) {
    throw new ActivityResetException();      // same
  } else if (status.getActivityPaused()) {
    throw new ActivityPausedException();     // same
  }
  ...
} catch (Exception e) {
  processException(e);
}

The caller now sees the same exception for a cancelled activity and for a failed heartbeat RPC. The only
way to tell them apart is to unwrap getCause().

The recordActivityTaskHeartbeatById branch has the same problem. The worker-side path does not.
HeartbeatContextImpl.sendHeartbeatRequest checks the flags outside its catch block, so
ActivityExecutionContext.heartbeat throws the specific type.

Specifications

• Version: 1.37.0
• Platform: