fix: await MQTT unsubscribe tokens during shutdown

[mah1104ahm]

Summary

• await each MQTT unsubscribe token during subscriber shutdown
• bound each wait with a one-second timeout and preserve the first failure
• always disconnect after unsubscribe attempts
• cover success, broker-error, and timeout paths

Verification

• gofmt on changed Go files
• go test ./internal/mqtt
• git diff --check

Closes #303

[xe-nvdk]

Thanks for the fix, this closes the gap #303 describes and the shape is right: the token wait is bounded, the first failure is preserved while the remaining topics still get their unsubscribe attempt, and the disconnect still always runs. I checked the mock against paho's Token interface (all four methods covered) and ran go test ./internal/mqtt on the branch, which passes.

Two asks before merging:

1. Please add a ## Fixed: entry to RELEASE_NOTES_2026.09.2.md for this, matching the entries the sibling PRs in this series carry (see #663 through #667 and #670).
2. One behavioral follow-through from Stop() now returning an error, in the inline comment.

[xe-nvdk]

Returning an error here changes behavior at two call sites in manager.go. StopSubscription and PauseSubscription return early when Stop() errors, which skips m.repo.UpdateStatus. At that point the subscriber is already deleted from m.subscribers and the client has disconnected, so the subscription is genuinely stopped while the persisted status keeps saying running, and retrying the stop returns ErrSubscriptionNotRunning, so the status stays wrong until the next start. (ListAutoStart selects on auto_start only, so nothing gets resurrected on restart; this is an API status consistency issue, not a data one.)

An unsubscribe timeout is most likely exactly when the broker is unreachable, so this path will happen in practice. Suggest having those two manager paths persist the status update even when Stop() reports an unsubscribe error, then return the error afterwards.

[mah1104ahm]

Thank you for catching the manager follow-through. I pushed a1ca9d3 after updating from main. StopSubscription and PauseSubscription now attempt the persisted status update even when unsubscribe fails, then return the shutdown and/or persistence error. I added regression cases for stop and pause under both broker-error and timeout conditions, checking persisted status, disconnection, and subscriber removal. The release note is included under Bug fixes in RELEASE_NOTES_2026.09.2.md, following the current contribution guide. Validation: go test ./internal/mqtt; go vet ./internal/mqtt; and the new manager regression with -race all passed locally. Ready for another review when convenient. M Ahmed

[xe-nvdk]

Re-reviewed a1ca9d3. Both asks are addressed: StopSubscription and PauseSubscription now persist the status update regardless of the unsubscribe outcome and return the joined error, and the release notes entry is in place with the credit line. Verified locally on the branch: go test ./internal/mqtt passes, and the new manager regression passes under -race for all four stop/pause x broker-error/timeout cases. Thanks for the thorough test coverage.