Prepare client for HTTP 202: accept all 2xx status codes in check_for_status

[Copilot]

When FlexMeasures server switches from returning 200 to 202 Accepted on certain endpoints, the client would raise a ValueError. check_for_status only accepted an exact status match, making the client fragile against server version differences.

Changes

• response_handling.py: check_for_status now accepts any 2xx status (200–299). Logs at INFO when the actual status differs from the expected one; raises ValueError for non-2xx codes unchanged.

# Before: only exact match passes
check_for_status(202, 200)  # → ValueError

# After: any 2xx passes, unexpected 2xx emits INFO log
check_for_status(202, 200)  # → logs "Received HTTP status 202 instead of expected 200."
check_for_status(400, 200)  # → ValueError (unchanged)

• tests/client/test_init.py: Added parametrized test cases covering exact-match success (no log), alternate 2xx success with INFO log, all common 2xx codes, and non-2xx boundary values (199, 300, 400, 404, 500, 503).

[coveralls]

Coverage Report for CI Build 25846640800

Coverage increased (+0.02%) to 96.27%

Details

• Coverage increased (+0.02%) from the base build.
• Patch coverage: 5 of 5 lines across 1 file are fully covered (100%).
• No coverage regressions found.

Uncovered Changes

No uncovered changes found.

Coverage Regressions

No coverage regressions found.

---

Coverage Stats

Relevant Lines:	697
Covered Lines:	671
Line Coverage:	96.27%
Coverage Strength:	5.78 hits per line

---

💛 - Coveralls

[Flix6x]

This PR makes the client accept 202, but does not yet update any expectation about it. That means that when the client starts to receive a 202 when forecasts/schedules are triggered, it still expects a 200, but will continue fine and just log an info statement. As soon as we know the FM version that moves from 200 to 202 for certain endpoints, we can update the client's expectations in accordance with the server version.