[HugoFara]

Fixes #231. I checked the port against Finney's code (github.com/mbedward/farsite, src/fsxwmech.cpp, Mechanix::ros). That code takes the wind in mph (×88 → ft/min) and the slope in degrees (tan). ForeFire passes m/s and a tangent along the normal, but the port kept:

• wind = windspd * 88: the wind counted 2.24× too weak. It now uses ×196.85, as Rothermel.cpp does.
• slopex = slope*2: this made the slope effect 4× too strong, and squaring lost its sign, so a 30% downslope spread 16× faster than flat ground. It is now max(slope, 0), upslope only, as in Rothermel. Farsite gets the same result by vectoring the steepest slope.
• A negative normal wind (backing) made pow() return NaN. The code then fell back to the no-wind rate and dropped the slope effect too. It is now clamped to 0.

On the repro from #231 (30% grade, no wind): 114 m upslope, 92 m downslope, 94 m on flat ground. The north/south difference reported in the issue doesn't come from the model: the 14-node front loses its tip node at t = 1000 s, which shortens the measured north extent.

Not touched: Farsite.adjustementWind is still read and unused.

Tests: 3 new unit cases: upslope only, a backing wind equals calm air, and the wind factor at 1 m/s matches Rothermel's formula. All 3 fail on dev. Unit 54/54, ctest 12/12.

This PR conflicts with #240 only in test_propagation_models.cpp, where both add cases at the same spot. I'll rebase whichever merges second.

Drafted with Claude Opus 5.5.

[antonio-leblanc]

Matches the mbedward/farsite reference and the other Rothermel models. I pushed the CHANGELOG entry, with a note that Farsite results change. Non-blocking: Farsite.adjustementWind is now dead, and "same result by vectoring the steepest slope" is closer to "same as ForeFire's Rothermel" than to Farsite's vector sum.