fix: skip CountWorkflow in batch operations when --yes is set

[bitalizer]

Closes #838.

Implements the design @cretz proposed in the issue thread: when --yes bypasses the confirmation prompt, skip the CountWorkflowExecutions request entirely.

What was changed

• internal/temporalcli/commands.workflow.go — SingleWorkflowOrBatchOptions.workflowExecOrBatch: CountWorkflow only runs in the !s.Yes branch.
• internal/temporalcli/commands.workflow_reset.go — same pattern in TemporalWorkflowResetCommand's batch path.

When --yes skips the count, the prompt text changes from Start batch against approximately N workflow(s)? y/N to Start batch against workflows matching query "<query>"? y/N, so the output (which promptYes still prints in the auto-confirm path) stays informative.

The non---yes interactive flow is untouched: it still counts, still prompts, still prints the same approximately N workflow(s) message.

Why

workflowExecOrBatch (terminate / signal / cancel) and the reset command both unconditionally call CountWorkflowExecutions before starting a batch. The result is only used to fill in the approximately N workflow(s) confirmation. When --yes is set, the prompt is skipped — but the count call still runs, and on clusters where the visibility API is timing out it fails the entire batch start. The original report is from a Postgres-backed cluster where the batch query itself works but the count times out; users can't start batch jobs they otherwise have permission to run.

How was this tested

Added TestWorkflow_Terminate_BatchWorkflow_SkipsCountWhenYes that:

1. Installs a unary gRPC interceptor that counts CountWorkflowExecutionsRequest and StartBatchOperationRequest calls.
2. Starts one workflow, then runs workflow terminate --query ... --yes.
3. Asserts: 0 CountWorkflow calls, 1 StartBatchOperation call, prompt text contains matching query and not approximately.

The interceptor pattern matches the existing testTerminateBatchWorkflow helper.

Ran the new test plus a sample of the existing batch tests locally; they pass. (TestWorkflow_Terminate_BatchWorkflowSuccess flakes locally on the unrelated Completed assertion both with and without my changes — pre-existing timing issue, not caused by this PR.)

[CLAassistant]

All committers have signed the CLA.

[chaptersix]

Overall: LGTM
Minor: prompt wording

The --yes path prints Start batch against workflows matching query "..."? y/N — but since promptYes is called with s.Yes=true, the user never sees this interactively. It appears in stdout as an auto-confirmed message, so the ? y/N suffix looks a bit odd in that context. Pre-existing issue, but worth noting.

Test

The test is thorough — interceptor pattern, gRPC call counting, Eventually for visibility lag. One nit: the drain at the end waits for run.Get to return a non-nil error after termination. That's correct, but it would be clearer to assert the error is specifically a termination error rather than just "not nil".

Missing coverage for workflow_reset.go

The test only covers workflow terminate. The reset path has the identical change but no corresponding test. Worth adding or at least noting.