Add standalone-activity support to throughput_stress (RE-353)

[lilydoar]

What was changed

Adds an include-standalone-activity scenario option to throughput_stress that starts activities outside any workflow context via StartActivityExecution and waits for the outcome with PollActivityExecution — mirroring the include-standalone-nexus pattern (#339) and bench-go's standalone-activity throughputstress step (bench-go #357/#358).

• kitchen_sink.proto: new ClientAction variant DoStandaloneActivity (field 7).
• Go client-action executor: Start + Poll implementation (30s start-to-close, 3 attempts), targeting the existing noop activity on the workflow's task queue. Runs for both the loadgen runner and the Go worker (shared executor).
• Java/Python/Ruby/TS/.NET workers raise UnsupportedOperation, exactly like standalone Nexus.
• Bindings regenerated via go run ./cmd/dev build-proto (Go, Java, Python, .NET).

Why

bench-go grew an EnableStandaloneActivity toggle (used by saas-cicd chasm e2e pipelines, with server dynamic config activity.enableStandalone) after the bench→omes parity scan closed. omes had no standalone-activity coverage at all — this closes that gap so the saas-cicd e2e cutover (RE-264) isn't blocked on it. RE-353, part of epic RE-257.

Notes for review

• Ruby generated proto (workers/ruby/.../kitchen_sink_pb.rb) is not covered by dev build-proto — if it's generated by a separate step, it needs a follow-up regen (the Ruby executor stub is in place).
• Server must support standalone activities; on unsupported servers the action fails — bench-go added a "short-circuit to success" for that case (bench-go bdd2879), which I deliberately did not replicate: the option is opt-in, so failing loudly on unsupported servers seems preferable. Open to changing.
• Validated: go build, go test ./scenarios/ ./loadgen/kitchensink/ pass. Not yet exercised against a server with activity.enableStandalone — needs a verification run before un-drafting.

[lilydoar]

Verification run (local, server 1.31.0 via temporal server start-dev):

go run ./cmd/omes run-scenario-with-worker --scenario throughput_stress --language go \
  --run-id verify353 --iterations 2 --option include-standalone-activity=true \
  --option internal-iterations=2 --server-address localhost:7233 --namespace default

Scenario completed cleanly, and temporal activity list confirms the standalone path was exercised end-to-end — 4 standalone activities (2 iterations × 2 internal iterations), all Completed, type noop, IDs matching the executor's scheme:

Completed  standalone-activity-w-verify353-7176d07159bb5746-1-a9dbbf7e-...  noop
Completed  standalone-activity-w-verify353-7176d07159bb5746-2-273892df-...  noop
...

One caveat: start-dev accepts standalone-activity APIs whether or not --dynamic-config-value activity.enableStandalone=true is passed (a control run without the flag also succeeded), so this validates the omes side but not the server-side gating — cloud/e2e environments still need activity.enableStandalone set, as the README section notes.

Also pushed: regenerated Ruby kitchen-sink bindings (workers/ruby/protos/.../kitchen_sink_pb.rb) — build-proto doesn't cover Ruby, so this was done with protoc --ruby_out plus the same temporalio/api/... require rewrite the file already used.

[GregoryTravis]

Approving for Java and Ruby