Standalone Activity: preserve server-generated request IDs across restarts

[dandavison]

What changed?

When generating a request ID server-side, set it on the request struct before any cloning so that the mutation is re-used by all retries.

Why?

Without this, there is a bug, although I have not attempted to repro it:

1. Request arrives at Frontend without requestID
2. Inside retry interceptor loop, requestID is generated and set on a cloned copy
3. Request proceeds to history, starts the execution, but then some networking condition in the cell causes RetryableInterceptor not to receive the Ack (it sees a context expiry)
4. Frontend retries, generating a new request ID. But meanwhile the activity has completed. This would be rare, but technically possible.
5. The default reuse policy permits a second execution to be started. This would be a bug: the second start should have been prevented by the request ID. If the user's activity lacks idempotency protection it will lead to incorrectness in the user's systems.

How did you test it?

It would be hard to repro that bug.

• built
• added weak new unit test(s) for the Start case.

Potential risks

Could introduce incorrectness into Standalone Activity

---

Note

Medium Risk
Touches standalone activity request-id generation/dedup behavior; mistakes could affect idempotency (duplicate starts/cancels/terminations) but the change is small and covered by a unit test for the start path.

Overview
Ensures standalone activity frontend operations re-use a single RequestId across retry attempts by generating the ID on the original request before cloning/mutation in validateAndPopulateStartRequest, and by no longer cloning requests when auto-populating RequestId for TerminateActivityExecution and RequestCancelActivityExecution.

Adds a unit test (TestRequestIdStableAcrossRetries) that calls validateAndPopulateStartRequest twice with the same request pointer and asserts the RequestId stays stable for both server-generated and client-provided IDs.

^{Written by Cursor Bugbot for commit 38bd190. This will update automatically on new commits. Configure here.}

[stephanos]

fwiw, in my PR now I've moved this into the validation and normalization methods like this:

    if req.GetRequestId() == "" {
		req.RequestId = uuid.NewString()
	} else if len(req.GetRequestId()) > config.MaxIDLengthLimit() {
		return serviceerror.NewInvalidArgumentf("request_id exceeds length limit. Length=%d Limit=%d",
			len(req.GetRequestId()), config.MaxIDLengthLimit())
	}

[bergundy]

Just FTR, the duplicates can easily happen if a client retries and doesn't specify a request ID. This makes it a bit worse.