BUG: apply wind factors to the ensemble member that was selected

[thc1006]

Pull request type

• Code changes (bugfix, features)

Checklist

• Tests for the changes have been added (if needed)
• Docs have been reviewed and added / updated
• Lint (ruff check / ruff format --check) has passed locally
• All tests (pytest tests/unit tests/integration) have passed locally

Current behavior

StochasticEnvironment.create_object() walks the generated dictionary and, when it meets ensemble_member, calls select_ensemble_member(). That call rebuilds the wind functions from the chosen member's own profile.

ensemble_member sits in exception_list, so _set_stochastic() skips it and _validate_ensemble() sets it after the base constructor has already put the wind factors in __dict__. The factors are therefore reached first, scaled into whichever member was loaded at construction, and then overwritten.

With two members whose winds are 10 and 30, member 1 selected and a factor of 2, the flight gets 30. The input record still says the factor was applied.

StochasticEnvironment(
    environment=ensemble_env,
    ensemble_member=[1],
    wind_velocity_x_factor=(2.0, 0),
)

A determinism test would not catch this: the same seed is consistently wrong.

New behavior

Factors are collected during the loop and applied after it, so which entry __dict__ happens to hold first no longer decides the result. When a member was selected, the baseline is the profile that member just loaded; otherwise it is the construction-time value, so repeated calls still do not compound.

The example above now gives 60.

Breaking change

• No

Runs that combined an ensemble with a wind factor were silently ignoring the factor, so their results change. That was the bug.

Additional information

Three tests, filling the test_validate_ensemble gap that was commented out in tests/unit/stochastic/test_stochastic_environment.py:

• the selected member's wind is scaled, rejecting both 30 (factor dropped) and 20 (member 0's cached wind)
• repeated create_object() calls stay at 60 rather than compounding
• without ensemble members the factor still multiplies the construction value

Reverting the fix turns the first two red; so does keeping the construction-time baseline after a member switch. The third stays green under both, which is what tells them apart.

Local run against develop at 1d04bcc: ruff clean, pylint exit 0, pytest tests/unit tests/integration 2216 passed, 51 skipped.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 83.56%. Comparing base (e0ff281) to head (8c37fbb).
⚠️ Report is 61 commits behind head on develop.

Additional details and impacted files

@@             Coverage Diff             @@
##           develop    #1160      +/-   ##
===========================================
+ Coverage    82.18%   83.56%   +1.37%     
===========================================
  Files          122      130       +8     
  Lines        16355    17088     +733     
===========================================
+ Hits         13441    14279     +838     
+ Misses        2914     2809     -105     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.