Extract shared _dispatch helper for annotation service _send_* methods

[craigmcchesney]

The annotation-service feature clients now contain many near-identical _send_* methods that differ only in the stub method called, the success oneof field name, the result class, and the operation name used in log/error messages. PvMetadataClient has 4; MachineConfigClient has 9. Once #6 (annotations) lands there will be ~14+ of these across the annotation clients.

Each body is the same three-tier error-handling shape:

try:
    response = self._stub.<op>(request)
    if response.HasField('exceptionalResult'):
        return <ResultCls>(is_error=True, message=response.exceptionalResult.message)
    elif response.HasField('<successField>'):
        return <ResultCls>(is_error=False, message="", response=response)
    else:
        return <ResultCls>(is_error=True, message="Unexpected response format: ...")
except grpc.RpcError as e:
    return <ResultCls>(is_error=True, message=f"gRPC error: {e.details()}")
except Exception as e:
    return <ResultCls>(is_error=True, message=f"Unexpected error: {e}")

Proposal: extract a shared helper (e.g. on ServiceApiClientBase) roughly:

def _dispatch(self, stub_call, request, result_cls, success_field, op_name): ...

that runs the RPC, applies the three-tier handling, and returns the built result object. Each _send_* collapses to a one-line delegation.

Why not now: during the #9 code review (PR #12) this was deliberately deferred — refactoring in that PR would have made it inconsistent with the existing house style in IngestionClient/PvMetadataClient, and the full extent of the duplication isn't visible until the third annotation feature client (#6) exists. This issue tracks doing it as a dedicated cleanup once #6 is merged.

[craigmcchesney]

Sequencing decision (2026-09-09, while planning #6): land this refactor before #6 rather than after it.

The "wait until #6 so the full duplication is visible" rationale is satisfied by the #6 plan (plan/tickets/6/plan.md), which fixes the complete call-site set: 17 unary _send_* bodies exist today — PvMetadataClient 4, MachineConfigClient 9, SampleStatusClient 3, QueryClient 1 — and #6 adds 11 more (saveDataSet, getDataSet, queryDataSets, deleteDataSet, saveAnnotation, getAnnotation, queryAnnotations, deleteAnnotation, getCalculations, exportData, plus paging over the two queries). The two server-streaming senders (querySampleStatusesStream, querySamplesStream) iterate a response stream and stay as they are.

Doing it first means each new #6 sender is a short delegation instead of ~40 lines of the same three-tier block, and the existing 406 unit tests cover the refactor as-is — they mock the stub method, which _dispatch still calls. Own small PR, off main, before the #6 feature branch.

[craigmcchesney]

Correction (2026-09-09, from the review of #42): the counts above are off by one on both sides. Today there are 18 unary _send_* bodies, not 17: the 16 on the annotation-service clients plus QueryClient._send_query_samples and IngestionClient._send_register_provider, which have the identical three-tier shape. And #6 adds 10, not 11, one per unary RPC (saveDataSet, getDataSet, queryDataSets, deleteDataSet, saveAnnotation, getAnnotation, queryAnnotations, deleteAnnotation, getCalculations, exportData); iter_* paging reuses the query sender and adds none.

Scope decision, recorded in the plan (finding 5 / Q3): _dispatch goes on ServiceApiClientBase and covers all 18, not only the annotation clients. The two server-streaming senders (querySampleStatusesStream, querySamplesStream) stay as they are.