MEB safety: rejected steering command permits a power increase while controls are disabled

I found a two-message sequence that bypasses the MEB steering-power wind-down check on opendbc commit `057aee25b5eee7530f0b95b5b508c8c3247b0cd7`.

It reproduces with `volkswagenMeb` safety parameters 0 and 2.

With the normal MEB test setup, controls start disabled and the power reference is zero:

```python
def test_rejected_power_does_not_allow_increase(self):
self.assertFalse(self._tx(self._curvature_cmd_msg(0, power=50)))
self.assertFalse(self._tx(self._curvature_cmd_msg(0, power=49.6)))
```

Both messages request steering with zero curvature. The DBC power values `50` and `49.6` encode raw power bytes `125` and `124`.

**Expected:** both messages are rejected. Although decreasing power is permitted during disengagement wind-down, neither command decreases from the initial reference of zero.

**Actual:** the first message is rejected, but the second is accepted.

In `steer_curvature_cmd_checks()`, this assignment runs even when the command has violated a safety check:

```c
curvature_state.steer_power_last = steer_power;
```

The rejected command therefore raises the reference to 125, making the subsequent 124 appear to be a valid decrease.

The minimal failing test is in [this commit](https://github.com/andrewchambers/opendbc/commit/73fd83efc07c0a2a82753d8957e6dfcf3d1da902). Running:

```bash
python -m unittest opendbc.safety.tests.test_volkswagen_meb
```

fails at the second assertion for both MEB variants.

Start with steer_curvature_cmd_checks() and the MEB safety tests in opendbc.safety.tests.test_volkswagen_meb. Run python -m unittest opendbc.safety.tests.test_volkswagen_meb and inspect the failing second assertion for volkswagenMeb parameters 0 and 2. Done means both rejected commands remain rejected and the test passes for both variants.

Written by the indexing model from the issue text.