fix: a test still described the control the cap replaced (4295)

Run 7367, integration lane:

    FAILED test_a_cap_is_stored_even_when_it_cannot_be_pushed
    assert True is False

The code was right. Raising a cap is PERMISSION, not a request — it
deliberately does not grow the pool, because that would put workers on a lane
with nothing to do, and the sizing pass spends the permission on its next tick
if there is work. So nothing is pushed and `applied` is vacuously true.

The test was carried over from when the number meant "run this many", where
every write pushed. It asserted the old control's behaviour against the new
one — lesson #4338's shape again: an assertion encoding the thing that
changed, failing on the change rather than on a defect.

Split into the two cases that actually exist now:

- raising a cap stores it and pushes nothing, reporting applied;
- turning a lane OFF does push, because consumers follow the cap immediately
  in both directions — off must take effect when it is asked for — so with
  nothing answering it reports `applied: false` with a reason, and the value
  is still stored for the sizing pass to carry.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01LVjrnpQjRgHdvq95rASoiR

tests/test_api_workers.py

@@ -89,22 +89,47 @@ async def test_the_other_lanes_ship_at_one(client, no_live_workers):
 
 
 @pytest.mark.asyncio
-async def test_a_cap_is_stored_even_when_it_cannot_be_pushed(
+async def test_raising_a_cap_stores_it_and_pushes_nothing(
     client, db, no_live_workers,
 ):
-    """Nothing is answering, so the live push fails. That is NOT a failed
-    setting: the value is saved and the sizing pass carries it within a
-    minute (lesson #4202 — a live change that does not survive, with nothing
-    saying so)."""
+    """A cap is PERMISSION, not a request. Raising it must not grow the pool
+    here — that would put workers on a lane with nothing to do — so there is
+    nothing to push and `applied` is vacuously true.
+
+    This asserted `applied is False` until run 7367, carried over from when
+    the number meant "run this many". The code was right and the test was
+    describing the control it replaced.
+    """
     resp = await client.post("/api/system/workers/worker", json={"slots_cap": 3})
 
     assert resp.status_code == 200
     body = await resp.get_json()
     assert body["slots_cap"] == 3
+    assert body["applied"] is True
+    assert (await _lane_row(db, "worker")).slots_cap == 3
+
+
+@pytest.mark.asyncio
+async def test_turning_a_lane_off_is_stored_even_when_it_cannot_be_pushed(
+    client, db, no_live_workers,
+):
+    """The direction that DOES push. Consumers follow the cap immediately in
+    both directions — off must take effect when it is asked for — so with
+    nothing answering, the push fails.
+
+    That is NOT a failed setting: the value is saved and the sizing pass
+    carries it within a minute (lesson #4202 — a live change that does not
+    survive, with nothing saying so). The UI says "saved, not yet live"
+    rather than "that didn't work", which is the distinction `applied`
+    exists to carry.
+    """
+    resp = await client.post("/api/system/workers/worker", json={"slots_cap": 0})
+
+    assert resp.status_code == 200
+    body = await resp.get_json()
     assert body["applied"] is False
     assert "not running" in body["apply_error"]
-
-    assert (await _lane_row(db, "worker")).slots_cap == 3
+    assert (await _lane_row(db, "worker")).slots_cap == 0
 
 
 # --- the cap is the switch ---------------------------------------------------