[Feature Request] Schedules: support signal_workflow / signal_with_start_workflow as a ScheduleAction

[WilliamKnightX]

Is your feature request related to a problem? Please describe.
ScheduleAction only supports start_workflow. A common pattern is one long-running workflow per entity that receives work through signals and uses continue-as-new. Recurring work for that entity has to reach it as a signal, but a Schedule can't send one. Today we:

1. Have the Schedule start a short-lived "fire" workflow.
2. Have that workflow run an activity that calls SignalWithStartWorkflowExecution on the long-running workflow, because workflow code can't call signal-with-start.

That adds one extra workflow execution and one activity per fire. It also adds a second retry and timeout policy, and splits the history across two workflows. Overlap and catch-up policies end up applying to the throwaway workflow instead of to the work we care about.

This isn't specific to us. Any design with one workflow per entity (a mailbox or actor pattern with continue-as-new) that needs recurring work hits it. Temporal's own reference app for Orchestrating ambient agents with Temporal has the same workaround: in ensemble_nudge.py, a Schedule starts EnsembleNudgeWorkflow, whose activity signals the execution agent and starts it by hand on NOT_FOUND.

Describe the solution you'd like
New ScheduleAction variants:

• signal_workflow { workflow_id, signal_name, input, header }
• signal_with_start_workflow { NewWorkflowExecutionInfo + signal_name, signal_input }

The schedule time would be available to the receiver, the way TemporalScheduledStartTime is today, so receivers can deduplicate. ScheduleActionResult would record the target execution. Overlap policy could reasonably be a no-op for signal actions.

Describe alternatives you've considered

• Start the long-running workflow directly with a fixed ID. It's already running, so SKIP overlap drops the fire.
• Call describe on the schedule and signal the running workflow from the client. This needs an external process.
• A timer loop inside the long-running workflow. Cron/calendar specs, pause, and timezone handling all end up reimplemented in workflow code.

Additional context
Temporal Cloud, TypeScript SDK. That ambient-agents post was the starting point for our architecture: at Hazel we're building ambient agents on Temporal, with a mailbox workflow per user, child runs per nudge, and approvals that signal back into the run. It's been a great fit, and this is the one place we've had to work around the platform. Related forum threads: Signal to scheduled workflow, Schedule workflows that communicate through Temporal signals.

(Claude, for Will)