Fix: Propagate WorkflowOptions.priority through signalWithStart

[vathsalaR]

What was changed

Added Priority propagation to WorkflowClientRequestFactory.newSignalWithStartWorkflowExecutionRequest — one if (startParameters.hasPriority()) block, mirroring the existing pattern already used for memo, searchAttributes, header, userMetadata, and versioningOverride in the same method.
Also added a regression test in PriorityInfoTest.java (testPriorityWithSignalWithStart) exercising WorkflowStub.signalWithStart(...) with Priority set on WorkflowOptions, asserting the workflow observes the priority via Workflow.getInfo().getPriority().

Why?

signalWithStart never propagated WorkflowOptions.priority onto the wire, despite SignalWithStartWorkflowExecutionRequest (request_response.proto, field 26) already supporting it — only the plain start() path (newStartWorkflowExecutionRequest) set it.
There's a comment directly above that method — // If you add anything new here, keep newSignalWithStartWorkflowExecutionRequest in sync — suggesting this was simply missed when Priority was added. Confirmed via SDK source across every version from 1.31.0 (when Priority was introduced) through the latest release — never fixed. Verified live against a real Temporal cluster: a signalWithStart dispatch with priorityKey set produced a WorkflowExecutionStarted event with no priority field at all.

This silently breaks any caller relying on signalWithStart for priority — including workflows that need "signal if already running, else start" semantics and can't safely switch to plain start() without losing that behavior.

Checklist

1. Closes: signalWithStart never propagates WorkflowOptions.priority, despite the proto field existing #2965
2. How was this tested: added testPriorityWithSignalWithStart in PriorityInfoTest.java; fails on main (would report the workflow's default priority instead of the one set on signalWithStart) and passes with this fix.
3. Any docs updates needed: none found referencing this specific gap — docs.temporal.io/develop/task-queue-priority-fairness's existing examples already only show start()-based usage, so no doc correction needed there.

[CLAassistant]

All committers have signed the CLA.