Server: compute the fade-in gain once per channel per frame, not once per channel pair

**🤖 AI:** Follow-up to [ann0see/jamulus#293](https://github.com/ann0see/jamulus/pull/293#issuecomment-5625288666), opened at @ann0see's request.

**What is the current behaviour and why should it be changed?**

The [gain loop](https://github.com/jamulussoftware/jamulus/blob/292506ebb485f4fa98b56256aa6eb1b34be7d782/src/server.cpp#L899-L919) in `DecodeReceiveData` calls [`GetFadeInGain()`](https://github.com/jamulussoftware/jamulus/blob/292506ebb485f4fa98b56256aa6eb1b34be7d782/src/channel.h#L125) twice per channel pair, once for the source channel (line 909) and once for the target (line 915): 2N²−N int-to-float conversions and float divisions per frame, 44850 at N=150. The N values behind them are constant for the frame. Both counters are written only in `PutAudioData` and `OnNetTranspPropsReceived`, reached under `CServer::Mutex` from [`PutAudioData`](https://github.com/jamulussoftware/jamulus/blob/292506ebb485f4fa98b56256aa6eb1b34be7d782/src/server.cpp#L1586) and [`OnProtocolMessageReceived`](https://github.com/jamulussoftware/jamulus/blob/292506ebb485f4fa98b56256aa6eb1b34be7d782/src/server.cpp#L1572), and [`OnTimer` holds that mutex](https://github.com/jamulussoftware/jamulus/blob/292506ebb485f4fa98b56256aa6eb1b34be7d782/src/server.cpp#L669-L727) for the whole decode phase, single- or multithreaded.

**Describe possible approaches**

Read each connected channel's fade-in gain once into a `CVector` in the loop that [builds `vecChanIDsCurConChan`](https://github.com/jamulussoftware/jamulus/blob/292506ebb485f4fa98b56256aa6eb1b34be7d782/src/server.cpp#L672-L683), and multiply by `vecfFadeInGains[j]` and `vecfFadeInGains[iChanCnt]` at lines 909 and 915 — #293's one-read-per-channel pattern applied to the remaining per-pair accessor, independent of that PR. The output is unchanged: a [benchmark of the two loop shapes](https://gist.github.com/mcfnord/1625d81e5243cdf727439704b73ebf70) with a lock-free gain read produces byte-identical matrices at N=50, 100 and 150, and times the fade-in term alone (Raspberry Pi 4 Model B, g++ 14.2 `-O2`, median of 5 batches, 64-sample frame):

| N | per pair | per frame | saving | share of a 1.33 ms frame |
|---:|---:|---:|---:|---:|
| 50 | 15.4 µs | 5.4 µs | 10.0 µs | 0.75% |
| 100 | 59.4 µs | 21.3 µs | 38.1 µs | 2.9% |
| 150 | 136.3 µs | 40.6 µs | 95.7 µs | 7.2% |

At the default 128-sample frame the microseconds are the same and the shares halve.

**Has this feature been discussed and generally agreed?**

Requested by @ann0see on #293; no PR until the design is agreed here.

---

🤖 *This message was written by AI and reviewed by @mcfnord.*

Comienza en src/server.cpp, en el bucle que construye vecChanIDsCurConChan, e inspecciona DecodeReceiveData; después, lee GetFadeInGain() en src/channel.h. Verifica que la ganancia de cada canal conectado se obtenga una vez por frame y se reutilice para ambos cálculos de pares, mientras la salida permanece sin cambios; usa el benchmark enlazado para comparar las formas de los bucles.

Escrito por el modelo de indexación a partir del texto del issue.