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.*

Beginne in src/server.cpp bei der Schleife, die vecChanIDsCurConChan aufbaut, und untersuche anschließend DecodeReceiveData; lies dann GetFadeInGain() in src/channel.h. Überprüfe, dass die Verstärkung jedes verbundenen Kanals einmal pro Frame abgerufen und für beide Paarberechnungen wiederverwendet wird, während die Ausgabe unverändert bleibt; verwende den verknüpften Benchmark, um die Schleifenformen zu vergleichen.

Vom Indexierungsmodell aus dem Issue-Text verfasst.