**What changed and why?**

Propagation refers to how time-skipping config is carried over to all
workflows started by the current workflow: retry, continue-as-new, child
workflows, reset, etc.

1. Remove **disable_propagation** and **max_target_time**, because
neither of them can be soundly defined when time-skipping propagates
transitively across related workflows. One of the many examples:

- max_target_time: as an absolute time point, it may already have passed
by the time a retry or downstream workflow starts, making it ambiguous
whether to disable or preserve time-skipping — neither is a clearly
correct default
- disable_propagation: it is unclear which type of transitively
triggered workflow this should apply to, and treating all cases
uniformly is unreasonable; we defer exposing this flexibility until user
demand and use cases are better understood

2. Add **comments of the propagation behavior** for each feature (retry,
continue-as-new, child workflow, reset, cron)
3. Add **comments to the bound field**
4. Add **propagatedSkippedDuration** to time skipping config so that new
workflows can inherit the virtual time

** Breaking changes to API **
1. deleted fields and reused the numbers since the TimeSkippingConfig is
not yet released

## What
Add `worker_commands` bool field to capabilities.

## Why
This feature requires SDK to implicitly create a new task queue and
poller per process. Preferable to do this in a controlled manner.

## How did you test it?
Build

🤖 Generated with [Claude Code](https://claude.com/claude-code)

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

<!-- Describe what has changed in this PR -->
**What changed?**
- Specify resourceID for TriggerWorkflowRule api

<!-- Tell your future self why have you made these changes -->
**Why?**
- Specify resourceID for TriggerWorkflowRule api

<!-- 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. -->
**Server PR**

<!-- Describe what has changed in this PR -->
**What changed?**
Added weak_consistency boolean field to `DescribeNamespaceRequest`. When
set to `true`, the server may serve the response from an
eventually-consistent source (e.g. the in-memory namespace registry)
instead of reading through to persistence.

<!-- Tell your future self why have you made these changes -->
**Why?**
`DescribeNamespace` currently always reads through to the persistence
store. The new field lets clients opt into eventually-consistent reads
where read-after-write semantics aren't required, while preserving the
existing strong-consistency contract for operator/admin callers (default
behavior unchanged).

<!-- Are there any breaking changes on binary or code level? -->
**Breaking changes**
None. Additive field with default `false`, preserving current behavior
for clients that don't set it.

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

**What changed?**
Add `{Pause/Unpause/Reset/Update}ActivityExecution` RPCs and
corresponding request/response pairs that will target both workflow
embedded and standalone activities. These all strictly target a single
activity by ID, if a workflow_id is specified on the request the
operation targets a workflow activity.

**Why?**
Unified support for activity operations.

**Breaking changes**
None

**Server PR**
Does not break server

## What
Add `bool include_system_workers` field to `ListWorkersRequest` proto.
When true, the response includes system workers that are not created by
the user. By default, system workers are excluded.

## Why
System workers (per-namespace workers for scheduler, batcher, etc.) show
up in ListWorkers results, which is confusing for users who only care
about their own workers.

## How did you test it?
Build

🤖 Generated with [Claude Code](https://claude.com/claude-code)

---------

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

## What changed?

Add `standalone_nexus_operations` to `NamespaceInfo.Capabilities`.

## Why?

Allows `DescribeNamespace` callers to determine whether standalone Nexus
operations are available for a namespace.