Fix multicaster race that leaves a new downstream without a producer

[MartinStrambach]

The bug

StoreChannelManager keeps a stale producer reference after the producer has been cancelled. When the last downstream is removed, doRemove calls producer?.cancelAndJoin() but does not clear the field — it waits for the producer's UpstreamFinished message to do that. That message is sent asynchronously from SharedFlowProducer.start()'s joiner coroutine, so there is a window in which an AddChannel message is processed first:

1. AddChannel(#2) → doAdd → activateIfNecessary() sees producer != null (dead) → upstream is not restarted.
2. UpstreamFinished → doHandleUpstreamClose: nothing was dispatched (dispatchedValue == false), so with piggybackingDownstream = true the new downstream is parked as piggybacked, producer is set to null, and reactivation only happens for leftovers (empty).

The new downstream now hangs forever with zero emissions. It only recovers if some later downstream on the same multicaster restarts the producer, which dispatches to piggybacked channels too.

The ordering is easy to hit in practice: Multicaster.newDownstream() sends RemoveChannel from onCompletion and AddChannel from onStart, so cancelling a collector and immediately re-collecting (a routine "restart the subscription" pattern, e.g. flatMapLatest-style UI code over store.stream()) races the resubscribe against the in-flight UpstreamFinished. Since FetcherController builds its multicaster with piggybackingDownstream = true, the visible symptom at the Store level is store.stream() collectors that never receive anything — we tracked down a production "infinite loading" bug in our app to exactly this race.

The fix

Clear the producer reference in doRemove immediately after cancelAndJoin(), so a subsequent AddChannel starts a fresh producer. This is safe:

• The actor processes messages sequentially, so no concurrent access to the field.
• The cancelled producer's late UpstreamFinished is already ignored by the identity check at the top of doHandleUpstreamClose (if (this.producer !== producer) return).

Testing

Added a deterministic regression test in StoreChannelManagerTests. It runs on a single-threaded test dispatcher and exploits the actor's rendezvous channel: while the actor is suspended in doRemove's cancelAndJoin(), the next addDownstream parks as a pending sender ahead of UpstreamFinished, reproducing the exact production ordering. The upstream suspends on its first collection (fetch in flight, then cancelled) and emits on the second.

• Before the fix: the test fails with expected:<1> but was:<null> — the second downstream never receives a value.
• After the fix: :multicast:jvmTest, :store:jvmTest, and :multicast:ktlintCheck all pass.