fix(worker): stop forcing WorkerStopTimeout to zero

[xepozz]

Reason for This PR

[Author TODO: add issue # or explain reasoning.]

Description of Changes

The option travels from the PHP SDK's WorkerOptions and was discarded, so worker.Stop awaited nothing: in-flight task handlers were dropped instead of drained. PHP is the only SDK that fails the cross-SDK worker_shutdown/poll_complete_on_shutdown feature because of it.

License Acceptance

By submitting this pull request, I confirm that my contribution is made under
the terms of the MIT license.

PR Checklist

[Author TODO: Meet these criteria.]
[Reviewer TODO: Verify that these criteria are met. Request changes if not]

• All commits in this PR are signed (git commit -s).
• The reason for this PR is clearly provided (issue no. or explanation).
• The description of changes is clear and encompassing.
• Any required documentation changes (code and docs) are included in this PR.
• Any user-facing changes are mentioned in CHANGELOG.md.
• All added/changed functionality is tested.

[rustatian]

omg, what is that test testing? Like, in Go, you can assign a value to a field? Please stop writing sloppy tests.

[xepozz]

it fixes the unexpected behavior that drop the timeout config to 0 inside

[rustatian]

It is not about what is fixed; it is about the test. This test tests nothing except that, in Go, you can set a value to a struct field. Because you literally pass a config to the method and check if that field is set. Literally a = 5, assert a == 5.
In the era of AI, you have to understand at least what you are changing and how that should be tested.
And as I see it, since your AI at least wrote the correct description: The option travels from the PHP SDK's WorkerOptions and was discarded - this should be tested, not by calling the method directly in Go, but you need to write a test in which PHP sets this option, and then you need to check that this option is actually set by observing logs or using other options.

[xepozz]

Could be interesting to read https://guitton.co/posts/code-reviews-cheatsheet

[rustatian]

Great reading, thank you. I do like this point in the - be great submitter section:

[rustatian]

@xepozz Instead of rage-closing the PR with the change, which is probably needed for the project, you may simply ask: I want this change; I don't know how to correctly test it - suggest to me how to do that.

Or send a PR with the change but w/o tests, and in the same way, like in your link, simply ask maintainers: guys, I don't know how to test this; please advise me. If I needed to send a patch to a PHP (because I don't know PHP, as you know) project, I'd ask 1000 times the mainteiner how to make the change in a way he'll accept it, instead of wasting his time with AI slop.

Here is your change: 4ad9e33, I'll merge it soon. Please look at the test and the logic behind the test. If the change connects both worlds, PHP and Go, the test should start from PHP, but not as I explained in the thread above.