feat: scheduled primitives — standalone Nexus operation support (stacked on #2)

[chaptersix]

Summary

Stacks on #2. Adds standalone Nexus operations as the second primitive under the schedule-action extension model. Mirrors the activity-primitive shape from the parent PR — no new lifecycle, no new ScheduleActionResult/Info fields, just new oneof variants in the extension seams.

Changes:

• temporal/api/nexus/v1/message.proto: adds NewNexusOperationExecutionInfo, a shared config message for starting a standalone Nexus operation in different contexts (mirrors NewWorkflowExecutionInfo and NewActivityExecutionInfo). Carries operation-specific config (operation_id, endpoint, service, operation, input, the three timeouts, search_attributes, nexus_header, user_metadata). Request-level fields (request_id, id_reuse_policy, id_conflict_policy) stay on StartNexusOperationExecutionRequest and are not part of the schedule action config.
• temporal/api/schedule/v1/message.proto:
  • ScheduleActionKind: adds SCHEDULE_ACTION_KIND_NEXUS_OPERATION = 3.
  • ScheduledExecutionReference: adds ScheduleNexusOperationExecution nexus_operation = 3 variant.
  • New ScheduleNexusOperationExecution message (operation_id, run_id) — typed running-execution handle for the generic running_executions list.
  • ScheduleAction: adds start_nexus_operation = 3 variant referencing NewNexusOperationExecutionInfo. The scheduler generates a unique operation_id per run (mirrors the activity_id rule on start_activity).

The generic ScheduleActionResult.start_execution_* fields, ScheduleInfo.running_executions, and ScheduleListInfo.action_kind / action_type_name introduced in #2 already cover Nexus operations — no further field changes here.

Verification

• buf build — passes
• buf lint — passes
• buf breaking --against upstream/master — passes (no breaking changes)

Test plan

• Regenerate api-go bindings on top of this stacked branch
• Wire start_nexus_operation dispatch through the scheduler (downstream PR)
• Manual e2e: create schedule with start_nexus_operation, observe running_executions and recent_actions[].start_execution_result