Fix receiver load balance threshold initialization

[FrankMartining]

Problem

NewReceiverBase creates the DownTrackSpreader before receiver options
are applied.

The spreader is therefore initialized with the default lbThreshold of
zero. WithLoadBalanceThreshold(20) is applied afterward, but
SetLBThreshold previously updated only the ReceiverBase field and not
the already-created spreader.

A zero spreader threshold is treated as 1,000,000, effectively disabling
parallel DownTrack writes for large rooms. This can cause forwarding
latency and packet queue buildup with large subscriber counts, especially
for single-layer screen share tracks.

Fix

• Propagate SetLBThreshold updates to the active DownTrackSpreader.
• Protect threshold reads and writes with the spreader mutex.
• Add a regression test for updating the threshold.

Testing

• go test ./pkg/sfu ./pkg/sfu/utils ./pkg/rtc -count=1
• go test -race ./pkg/sfu ./pkg/sfu/utils -count=1

[CLAassistant]

All committers have signed the CLA.

[devin-ai-integration]

✅ Devin Review: No Issues Found

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

[boks1971]

Thank you so much for catching this. Great catch!

Just some small comments,

• I think the test file can be removed. It is simple enough.
• Can you please add it to redreceiver.go and redprimaryreceiver.go also? I can take care of it if you would rather leave this at this point. Basically, do something like
  1. Add method to REDTransformer interface in receiver_base.go
  2. In SetLBThreshold, do loadREDTransformer and if not nil, call the method added to REDTransformer interface.
  3. Implement the method in those two RED files and pass it on to the spreader they have.

[boks1971]

this test can be removed. It is simple enough.

[boks1971]

I will merge this now and do the changes I suggested. Thank you once again for catching this.