Stop pinning the initial autoscaling poller count to the max in omes worker

[veeral-patel]

What was changed

--worker-{activity,workflow}-poller-autoscale-max=N set InitialNumberOfPollers as well as MaximumNumberOfPollers, so the flag quietly fixed the starting poller count at the ceiling. Dropping the two assignments lets the SDK apply its own initial default.

  options.ActivityTaskPollerBehavior = sdkworker.NewPollerBehaviorAutoscaling(sdkworker.PollerBehaviorAutoscalingOptions{
-     InitialNumberOfPollers: args.ActivityPollerAutoscaleMax,
      MaximumNumberOfPollers: args.ActivityPollerAutoscaleMax,
  })

and the same in the workflow-poller-autoscale-max block.

Previous code was a workaround to a SDK bug that's been since fixed.

• Fix Go worker autoscale behavior #253
• fix: run maxNumberOfPollers poller routines instead of initialNumberOfPollers sdk-go#2105

Will this cause a inconsistency with the omes workers in other languages?

No - I checked the other workers: Go is the only one coupling initial to max.

Harness	Call	Sets initial?
Python	PollerBehaviorAutoscaling(maximum=…) (worker.py:233)	no
TypeScript	{type: 'autoscaling', maximum: …} (worker.ts:250)	no
Java	new PollerBehaviorAutoscaling(null, max, null) (WorkerHarness.java:149)	no — positional (min, max, initial)
.NET	new PollerBehavior.Autoscaling(maximum: …) (Worker.cs:346)	no
Ruby	PollerBehavior::Autoscaling.new(maximum: …) (worker.rb:129)	no
Go (before)	{InitialNumberOfPollers: max, MaximumNumberOfPollers: max}	yes

⚠️ Behavior change

Below -max=5 you get initial=5, max=3: the SDK doesn't validate initial <= max and stores the initial target unclamped (internal_worker_base.go:956), so the worker transiently exceeds its own maximum. Verified not to error.

Nothing in this repo passes these flags. External command lines might be affected, if they are relying on initial being set to max. However, this should be rare as this is unexpected and incorrect behavior.

How was this tested

• Build, vet and tests pass