fix: two errors in the worker-lane tests (4291)

Both mine, both in tests/test_worker_lanes.py, neither in the code under
test. Run 7242.

RUFF I001 — two blank lines between the import block and the first
module-level comment. Rule 102 names this exact trap ("exactly ONE blank line
between imports and a module-level constant/comment/pytestmark") and I was
pointed at that rule repeatedly before opening it.

SIX FAILURES in test_worker_lane_check_constraints — the test asserted bare
constraint names, but Base.metadata's naming_convention has already applied
the `ck_worker_lane_` prefix by the time __table__.constraints is read.

The failure output is worth keeping: it shows the model emits exactly the
three intended constraints, prefixed once —

    ck_worker_lane_slots_non_negative  slots >= 0
    ck_worker_lane_cap_non_negative    slots_cap >= 0
    ck_worker_lane_slots_within_cap    slots <= slots_cap

— which is the model behaving correctly, and confirms the migration's
op.f() names match what the ORM produces.

The assertion is now an equality against the prefixed names plus an explicit
check for a doubled prefix. That is strictly more valuable than what I wrote:
a bare-name assertion would have passed just as happily against
`ck_worker_lane_ck_worker_lane_slots_within_cap`, which is the defect alembic
0088 had to rename four constraints for (#3275).

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

tests/test_worker_lanes.py

@@ -11,7 +11,6 @@ import pytest
 
 from backend.app.services import worker_lanes as wl
 
-
 # --- the lane definitions ----------------------------------------------------
 
 
@@ -248,9 +247,20 @@ def test_worker_lane_check_constraints(slots, cap, ok):
         c.name: str(c.sqltext) for c in WorkerLane.__table__.constraints
         if hasattr(c, "sqltext")
     }
-    assert "slots_within_cap" in constraints
-    assert "slots_non_negative" in constraints
-    assert "cap_non_negative" in constraints
+    # The names carry the convention's `ck_worker_lane_` prefix ALREADY — the
+    # model declares them bare and Base.metadata's naming_convention applies it.
+    # Asserting the prefixed form is what pins the thing that actually went
+    # wrong once: alembic 0088 had to rename four constraints that shipped as
+    # `ck_x_ck_x_name`, because the migration pre-prefixed a name the
+    # convention then prefixed again (#3275). A bare-name assertion here would
+    # pass just as happily against a doubled one.
+    assert constraints == {
+        "ck_worker_lane_slots_non_negative": "slots >= 0",
+        "ck_worker_lane_cap_non_negative": "slots_cap >= 0",
+        "ck_worker_lane_slots_within_cap": "slots <= slots_cap",
+    }
+    for name in constraints:
+        assert not name.startswith("ck_worker_lane_ck_"), f"doubled prefix: {name}"
 
     # Evaluate the same predicates the database will, so the parametrize table
     # documents what is accepted rather than restating the SQL.