Fix missing ticker.Stop() in pollForSettingChanges

[GiGurra]

Summary

• pollForSettingChanges creates a time.NewTicker but never calls Stop() on it when the context is cancelled, leaking the ticker's internal runtime timer
• Other functions in the same file (heartbeatLogLoop, reportQueueStatusLoop) correctly use defer ticker.Stop() — this aligns with that pattern
• Note: pollForSettingChanges only runs when no notifier is configured (poll-only mode), so this only affects non-LISTEN/NOTIFY setups

Test plan

• Existing TestProducer_PollOnly exercises this code path
• Existing test suite passes

🤖 Generated with Claude Code

[brandur]

@GiGurra Can you add yourself to the CLA repo? https://github.com/riverqueue/rivercla

[GiGurra]

@GiGurra Can you add yourself to the CLA repo? https://github.com/riverqueue/rivercla

Alright, something like this, right?
riverqueue/rivercla#20

[brandur]

@GiGurra Yep, that'll do it.

[brandur]

@GiGurra Thanks! This looks good.

Just heads up: we don't have a clear policy on AI-generated contributions right now, but we may have to consider adding a little bit of friction to the process because if they become large in number (e.g. what projects like Ghostty are seeing right now), they could easily overwhelm our review bandwidth.

These changes largely look pretty legitimate though, so no worries for now. In case you do send more, would you mind compacting the commit messages a bit more? The summary section is okay, but I don't think we need the list of checkboxes.

[GiGurra]

@GiGurra Thanks! This looks good.

Just heads up: we don't have a clear policy on AI-generated contributions right now, but we may have to consider adding a little bit of friction to the process because if they become large in number (e.g. what projects like Ghostty are seeing right now), they could easily overwhelm our review bandwidth.

These changes largely look pretty legitimate though, so no worries for now. In case you do send more, would you mind compacting the commit messages a bit more? The summary section is okay, but I don't think we need the list of checkboxes.

Yes, no problem. I'll make sure to remove them in the future :) (I must admit I was a bit lazy in these PRs with regards to tweaking the auto generated descriptions and commit messages).

Full disclosure, I was quite lazy overall in these PRs, but I hope they can be of some use. Background: I had seen some odd performance degradations over time at work (where we use river). I wanted, initially just for fun, to let opus 4.6 have a look at the river source code, to see if it could find any obvious places for improvements (and potential culprits for our performance degradations). 3 of these 4 PRs are mostly just small things, but the jitter one could potentially be what we need to solve our problems at work.

[brandur]

Yes, no problem. I'll make sure to remove them in the future :) (I must admit I was a bit lazy in these PRs with regards to tweaking the auto generated descriptions and commit messages).

Awesome, thanks! And actually, I just noticed that the checkboxes are in the pull request description but not the commit messages, so actually, that's okay if you want to keep them going like that. (Mainly, just don't want them adding noise to Git history.)

Full disclosure, I was quite lazy overall in these PRs, but I hope they can be of some use. Background: I had seen some odd performance degradations over time at work (where we use river). I wanted, initially just for fun, to let opus 4.6 have a look at the river source code, to see if it could find any obvious places for improvements (and potential culprits for our performance degradations). 3 of these 4 PRs are mostly just small things, but the jitter one could potentially be what we need to solve our problems at work.

Nice! Yep, very cool.