_**READ BEFORE MERGING:** All PRs require approval by both Server AND
SDK teams before merging! This is why the number of required approvals
is "2" and not "1"--two reviewers from the same team is NOT sufficient.
If your PR is not approved by someone in BOTH teams, it may be summarily
reverted._

<!-- Describe what has changed in this PR -->
**What changed?**
Allow SDK to send empty deployment name for unversioned workers.

<!-- Tell your future self why have you made these changes -->
**Why?**
Need this to be able to remove the deprecated build ID field from
WorkerOptions.

<!-- Are there any breaking changes on binary or code level? -->
**Breaking changes**
No.

<!-- If this breaks the Server, please provide the Server PR to merge
right after this PR was merged. -->
**Server PR**
temporalio/temporal#9119

* Add test for multi-op err with resource exhausted

* validate second error

… (#686)

**What changed?**
- Added a new `worker_instance_key` field to `ShutdownWorkerRequest`, as
well as all other poll calls.
- Added comment to `ShutdownWorkerRequest.sticky_task_queue` saying it
may be blank, now that we've expanded the scope of when
`ShutdownWorkerRequest` is called.
- Added `task_queue` and `task_queue_kind` to `ShutdownWorkerRequest`

**Why?**
ShutdownWorker was changed to always be sent by SDK
(temporalio/sdk-core#1082), so sticky queue name
is now optional. This plus the new heartbeat info we send on shutdown
means Server will now have a more accurate map of which workers are
shutting down.

Adding task queue and task_queue_kind should also allow us to fix a lost
task issue, where there is a race when the SDK cancels an outstanding
poll rpc and the server decides to send a task to that poller.

Technically some of this info exists in the worker heartbeat part of the
message, but it needs to be lifted to its own field due to the scenario
where worker heartbeating is disabled.

**Breaking changes**
N/A I think, just adding new fields

**Server PR**

**What changed?**
Edit doc comments of `PollActivityTaskQueueResponse`.

**Why?**
To make it accurate for standalone activities.

**What changed?**
- Added a new CountSchedules API, symmetric to the other Count*
operations.

**Why?**
- Although it isn't documented as public API, the temporal UI makes use
of `ListWorkflowExecutions` to display the total count of schedules.
This operation will not return data for CHASM-based schedules.
Therefore, I'm introducing a public CountSchedules operation that the UI
(and customers) can make use of.

**Breaking changes**
- The technique of using `ListWorkflowExecutions` to query schedules was
always unsupported, so we aren't interested in supporting it for CHASM
schedules.
- `CountSchedules` will be implemented for both V1 and V2 schedules.

**Server**:
- [Server implementation
PR](temporalio/temporal#9046)

<!-- Describe what has changed in this PR -->
**What changed?**

Adds versioned API endpoint support for `PauseWorkflowExecution` and
`UnpauseWorkflowExecution` operations by adding `/api/v1/` HTTP bindings
alongside the existing unversioned paths.

<!-- Tell your future self why have you made these changes -->
**Why?**

The Go server configuration in [UI](https://github.com/temporalio/ui)
currently groups all API routes under `/api/v1/`.