Updater.addWorkflowTaskToMatching may be missing NotFound logging and build-ID assignment handling present in pushWorkflowTask

Expected Behavior

When a workflow task is added to matching via
Updater.addWorkflowTaskToMatching (used by Update-with-Start's
speculative WFT path), it should behave consistently with
pushWorkflowTask (used by the transfer queue active task
executor) for the same matchingClient.AddWorkflowTask call —
specifically:

1. Logging when matching unexpectedly returns a NotFound error
2. Updating the workflow's assigned build ID via
   initializeWorkflowAssignedBuildId when assignment rules are in use

Actual Behavior

addWorkflowTaskToMatching (service/history/api/updateworkflow/api.go:317)
builds the same AddWorkflowTaskRequest and calls
matchingClient.AddWorkflowTask, but returns immediately on
success without:

1. Logging if a NotFound error is unexpectedly returned
   (pushWorkflowTask logs this case explicitly, since it's
   not expected for AddTasks calls)
2. Calling initializeWorkflowAssignedBuildId to persist the
   assigned build ID returned in the response, when
   directive.GetUseAssignmentRules() is set

A TODO comment at the call site acknowledges this code was
copied from transferQueueActiveTaskExecutor.processWorkflowTask
and should be extracted into a shared helper, but the extraction
was never completed — leaving this functional gap.

This may mean worker build-ID assignment is not tracked
correctly for workflow tasks added via the Update-with-Start
speculative WFT path, though I have not yet confirmed user-visible
impact.

Steps to Reproduce the Problem

1. Compare service/history/api/updateworkflow/api.go:317
   (addWorkflowTaskToMatching) against
   service/history/transfer_queue_task_executor_base.go:147
   (pushWorkflowTask) — both construct the same
   AddWorkflowTaskRequest and call matchingClient.AddWorkflowTask
2. Note that pushWorkflowTask additionally logs on NotFound
   and calls initializeWorkflowAssignedBuildId(...) on success
   when assignment rules are in use
3. Observe that addWorkflowTaskToMatching has neither behavior,
   returning nil immediately after a successful matching call

Specifications

• Version: present on latest main
• Platform: any

Start by comparing addWorkflowTaskToMatching in service/history/api/updateworkflow/api.go with pushWorkflowTask in service/history/transfer_queue_task_executor_base.go. Trace the matchingClient.AddWorkflowTask response and the existing initializeWorkflowAssignedBuildId call; done means the speculative WFT path handles unexpected NotFound results and assigned build IDs consistently with pushWorkflowTask.