Improve handling of CANCELLED errors in the dispatch layer #3300

CANCELLED at the server level should mean "the client cancelled the request and went away." Currently, with the way that our dispatching layer works, a dispatching gRPC client can return with a CANCELLED error at its layer and then that bubbles up to the caller, which obscures what's going on at the server level.

A couple things here:

1. Wrap the dispatcher remote boundary to catch CANCELLED errors and turn them into UNAVAILABLEs if the caller's context isn't already cancelled. This happens in internal/dispatch/remote/cluster.go at lines 206, 780, 731, and 744. Make sure the context check is done on the dispatcher's inbound context rather than the hedging context.
2. Make hedging cancels more visible with context.WithCancelCause in cluster.go at lines 552 and 557. We use this pattern at internal/graph/cursors.go:451, and we work around the lack of this pattern at internal/graph/lookupsubjects.go:354.