Standalone Activities start delay

[GregoryTravis]

Add setStartDelay(Duration) to StartActivityOptions for Standalone Activities.

Mirrors the existing WorkflowOptions.setStartDelay(...) semantics on the activity side. When set, the server creates the activity immediately (visible in describe/list responses with status RUNNING, run state SCHEDULED) but defers dispatch to a worker until the delay elapses.

Spec

• 1-pager: https://app.notion.com/p/3308fc56773880bc9a40d6886275c0ef

Public API surface

StartActivityOptions opts =
    StartActivityOptions.newBuilder()
        .setId("act-1")
        .setTaskQueue("tq")
        .setStartToCloseTimeout(Duration.ofSeconds(60))
        .setStartDelay(Duration.ofSeconds(30))   // ← new; non-negative
        .build();
client.start(MyActivity.class, MyActivity::run, opts);

• Added setStartDelay(Duration) to StartActivityOptions.Builder
• Client-side validation: throws IllegalArgumentException if negative

Differences from the cross-SDK siblings

Behavior covered by tests

#	Test	Verifies
1	StartActivityOptionsTest::testNegativeStartDelayFails (unit)	IllegalArgumentException raised at setter time for negative values
2	StartActivityOptionsTest::testZeroStartDelayAccepted (unit)	Duration.ZERO accepted as a valid value
3	StartActivityOptionsTest::testToBuilderPreservesAllFields (unit, extended)	startDelay survives toBuilder() round-trip
4	StandaloneActivityTest::testStartDelayDelaysFirstDispatch	lastStartedTime − scheduledTime >= startDelay − 500ms
5	StandaloneActivityTest::testZeroStartDelayBehavesAsUnset	Duration.ZERO produces near-immediate dispatch
6	StandaloneActivityTest::testCancelDuringStartDelay	cancel() cancels immediately
7	StandaloneActivityTest::testTerminateDuringStartDelay	terminate() cancels immediately
8	StandaloneActivityTest::testStartDelayPreservesScheduleToStartTimeout	scheduleToStartTimeout = 1s + startDelay = 2s dispatches successfully
9	StandaloneActivityTest::testStartDelayPreservesScheduleToCloseTimeout	Same, with scheduleToCloseTimeout = 1s + startDelay = 2s for SchedToClose
10	StandaloneActivityTest::testStartDelayNotReappliedOnRetry	Retry attempts don't re-apply the delay.

Test environment

.github/workflows/ci.yml:

• Bumped TEMPORAL_CLI_VERSION from 1.7.0 to 1.7.1-standalone-nexus-operations. CLI v1.7.0 bundles server v1.31.0, which does not include the start-delay implementation
• Added --dynamic-config-value activity.startDelayEnabled=true to the dev-server args.