Cancel publication jobs when preparing for a full reconnect

[adrian-niculescu]

prepareForFullReconnect() clears the track publications, so the unpublishTrack() calls in republishTracks() can't find the old publications and never cancel their jobs. Each full reconnect therefore leaks the feature collector of every published audio track, which keeps running and sends UpdateLocalAudioTrack with the sid of the replaced publication whenever the track's features change.

Cancel the jobs when preparing for the reconnect. Republishing creates fresh jobs for the new publications.

The reconnect coroutine, publishAudioTrack, and unpublishTrack can all touch the jobs map from different threads, so job registration and draining are serialized: retiring paths remove the publication from trackPublications before draining its job, and registration re-checks under the same monitor that the publication is still current. That re-check alone can't tell a stale publish from a live one, since a publish accepted on the old session can resume after the teardown and re-insert its publication. Acceptances are therefore validated against a full reconnect epoch: each signal connection captures the epoch current when it opens, a TrackPublished response carries its connection's epoch, preparing a full reconnect advances the epoch, and the collector only starts when the acceptance's epoch is still current. Closing the old connection doesn't join an in-flight response handler, so a TrackPublished that already passed the connection guard can complete after the close and the epoch advance; carrying the epoch with the response keeps that acceptance attributed to the old session. A publish accepted by the replacement session registers normally, and soft reconnects preserve publishes without advancing the epoch.

Split out of #987, which was closed since its main feature turned out to be unnecessary (#375). Five regression tests pin the behavior: a features change after a full reconnect produces exactly one update, a publish completing across reconnect preparation sends no stale-sid updates, an acceptance delivered by the old session after preparation is treated as stale, a publish accepted by the replacement session keeps reporting feature changes, and feature updates flow unaffected across a soft reconnect.

[changeset-bot]

🦋 Changeset detected

Latest commit: f961eb3

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
client-sdk-android	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[devin-ai-integration]

✅ Devin Review: No Issues Found

Devin Review analyzed this PR and found no potential bugs to report.

View in Devin Review to see 2 additional findings.