Add link field to propagate backlink in signal and signal-with-start …

…responses (#761)

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

Added `link` fields on `SignalWorkflowExecutionResponse` and
`SignalWithStartWorkflowExecutionRequest`. I think a singular link
should suffice but if reviewers feel otherwise (especially w.r.t.
`SignalWithStartWorkflowExecutionRequest`) let me know.

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

To propagate backlinks on signal and signal-with-start executions back
to the caller.


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

Not a breaking change (unused field)


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

temporalio/temporal#9897

Add `CONTINUE_AS_NEW_VERSIONING_BEHAVIOR_USE_RAMPING_VERSION` (#760)

<!-- Describe what has changed in this PR -->
Add `CONTINUE_AS_NEW_VERSIONING_BEHAVIOR_USE_RAMPING_VERSION`


<!-- Tell your future self why have you made these changes -->
To enable the use case of Continue-as-new-upgrading a user-specified
cohort of Pinned workflows before any other workflows are upgraded. To
do this, user would first set Ramp percentage to zero, then tell (likely
via signal) their cohort of workflows to Continue-as-new with this
initial behavior, watch that bake, repeat for whatever other cohorts are
desired, and finally do a percentage-based ramp which applies to new
workflows as well as workflows doing
`CONTINUE_AS_NEW_VERSIONING_BEHAVIOR_AUTO_UPGRADE`


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


<!-- If this breaks the Server, please provide the Server PR to merge
right after this PR was merged. -->
Does not break the server

---------

Co-authored-by: Spencer Judge <sjudge@hey.com>

Patch v1.61.0 release with the fixed API route clashes (#757)

**What changed?**
Includes two commits for patching the `v1.61.0` release with a fix for
clashing API routes when standalone activities were introduced to the
server.
1. 7d69897 #717 
2. ff14265 #718

**Why?**
This version is broken in the UI

**Breaking changes**
No

**Server PR**
NA

---------

Co-authored-by: Roey Berman <roey@temporal.io>
Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>

add memo to schedule update request (#748)

<!-- Describe what has changed in this PR -->
**What changed?**
- add memo to `UpdateScheduleRequest`


<!-- Tell your future self why have you made these changes -->
**Why?**
- allow user to update their memo without recreating the schedule

Remove READ BEFORE MERGING warning (#741)

**What changed?**
Removing the warning from the PR template

**Why?**
GH now enforces this, no need to call out as the primary warning
mechanism

Add poller autoscaling namespace capability (#723)

Trampolining: addition of fields to remove the infinite loops for pin…

…ned wfs (#721)

_**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 -->
 -WISOTT


<!-- Tell your future self why have you made these changes -->
- Users that could using trampolining in the near future could run into
a problem, which shall only surface if the workflow author does not have
AutoUpgrade as the initial CAN behaviour for their Pinned workflows. As
of today, if a user does hit this case, they would have the pinned
workflow CAN'ing infinite number of times. This is because a pinned
workflow would commence on the pinned version (since it would have
inherited pinned version set to true) and if the pinned version is
different than a worker-deployment's current version, the
targetDeploymentVersionChanged would be set to true in the server. This
would then result in the workflow just CAN'ing all the time!
- This change aims to change that by only allowing at-most one CAN for
such pinned workflow executions, and it does so by remembering what the
initial version was at the start of the continue-as-new.


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


<!-- If this breaks the Server, please provide the Server PR to merge
right after this PR was merged. -->
- [PR!](temporalio/temporal#9374)

---------

Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>

Trampolining: addition of fields to remove the infinite loops for pin…

…ned wfs (#721)

_**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 -->
 -WISOTT


<!-- Tell your future self why have you made these changes -->
- Users that could using trampolining in the near future could run into
a problem, which shall only surface if the workflow author does not have
AutoUpgrade as the initial CAN behaviour for their Pinned workflows. As
of today, if a user does hit this case, they would have the pinned
workflow CAN'ing infinite number of times. This is because a pinned
workflow would commence on the pinned version (since it would have
inherited pinned version set to true) and if the pinned version is
different than a worker-deployment's current version, the
targetDeploymentVersionChanged would be set to true in the server. This
would then result in the workflow just CAN'ing all the time!
- This change aims to change that by only allowing at-most one CAN for
such pinned workflow executions, and it does so by remembering what the
initial version was at the start of the continue-as-new.


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


<!-- If this breaks the Server, please provide the Server PR to merge
right after this PR was merged. -->
- [PR!](temporalio/temporal#9374)

---------

Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>

Add worker_poll_complete_on_shutdown namespace capability (#719)

## What Changed
Adds a new namespace capability `worker_poll_complete_on_shutdown` to
indicate whether the server supports server-side completion of
outstanding worker polls on shutdown.

## Why
When this capability is enabled, the server will complete polls for
workers that:
1. Send `WorkerInstanceKey` in their poll requests
2. Call `ShutdownWorker` with the same `WorkerInstanceKey`

SDKs can check this capability via `DescribeNamespace` to decide whether
to rely on server-side poll completion or handle it client-side.

## How
- Added `bool worker_poll_complete_on_shutdown = 8` to
`NamespaceInfo.Capabilities` message in `namespace/v1/message.proto`

## Related PRs
- Server: temporalio/temporal#9323

Redo activity HTTP APIs (#716)

💥 **BREAKING CHANGE** 💥 

**What changed?**

- Redefined the experimental activity HTTP API paths.
- The activity operator APIs were explicitly marked as deprecated, they
will be redone when we add support for standalone activities.
- All verbs that didn't have an identifier in the path (e.g. APIs that
take a token), were renamed `activity-$VERB`.
- All APIs that take identifiers (either within a workflow or for
standalone) were restructured to include the identifiers in the path.
- Chose the name `resolve-as-canceled` for
`RespondActivityTaskCanceledById` to prevent the collision with `cancel`
with maps to `RequestCancelActivityExecution`, which matches the path
verb for `RequestCancelWorkflowExecution`.

**Why?**

The existing API paths have conflicts and aren't usable. Consistency and
future proofing.

**Breaking changes**

Yes, but the HTTP API is experimental.

**Server PR**

Not needed.