feat: the System tab is one bounded table, and the dial is the switch (4295)

Operator, 2026-09-23, on the screenshot: *"I feel that we can probably combine
the two sections into a single table and to format it in such a way that it
appears more bounded and less free-form or open. also there's nothing to
describe what 'auto' means or why their needs to be or should be on/off
toggles. almost all of it always needs to run there's only one optional piece
and it is killed by moving the 'cap' to zero."*

Three separate things, all correct.

## The four lanes were listed twice

The roster (milestone 365) said "ML tagging is running", and four hundred
pixels below it the lanes pane said "ML tagging · 1/1 busy". Two answers to
one question from two endpoints, free to disagree on screen. I moved the
second pane onto this tab yesterday and did not notice it duplicated the
first.

Now one row per part, with controls on the rows that have a lane and none on
the rows that do not. The join is on the QUEUE SET, because that is what
`service_roster` keys a celery part on — as a set, not as a string, so neither
side has to agree about order.

It lives in `utils/systemParts.js` rather than inline, and has a spec, because
its failure is SILENT and is the exact thing it exists to prevent: a lane that
stops matching its part does not throw, it grows a second row for the same
worker. The duplication, returning through the code that removed it.

## Bounded, not free-form

A real table — header, column rules, one bordered card — instead of dotted
rows floating on the page background with nothing saying where the list began
or what a column meant.

## The dial is the switch

There was an `On` switch per lane beside the slots dial. Of four lanes, three
must run for the application to work at all, so that switch offered a choice
that was never real — and for the one lane that IS optional, "off" and "zero
slots" were two ways of saying the same thing that could disagree with each
other.

So `enabled` is now DERIVED from the number: `set_lane` sets it from
`slots > 0` when the caller did not say. It stays on the API and in the model
— it is still the mechanism, and a drain-before-restart may still want a lane
holding its process with consumers cancelled without destroying the operator's
slot count to say so.

Two things fell out that a test now pins:

- The consumer command is sent on the CHANGE, not on the field being present.
  Otherwise every slots write re-sends a command that changes nothing —
  lesson #4183's churn, arriving through the new derivation.
- The model fetch fires on the off→on TRANSITION. It used to test `enabled is
  True`, the field having been sent. The UI no longer sends it, so the
  download that makes the ML lane usable would simply never have fired and the
  lane would have come on to consume a queue it had no model for.

## And Auto now says what it is

A legend under the table, in the operator's terms: what a slot is, that zero
turns a lane off, that three of the four are not optional, what `of N` means,
and that Auto lets a lane add slots by itself when its queue is backed up AND
every slot is busy — with why it is off by default, since it is the only thing
on the page that acts without being asked.

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

backend/app/services/worker_control.py

@@ -534,9 +534,33 @@ async def set_lane(
 
     new_cap = row.slots_cap if slots_cap is None else slots_cap
     new_slots = row.slots if slots is None else slots
-    new_enabled = row.enabled if enabled is None else enabled
     new_autoscale = row.autoscale if autoscale is None else autoscale
 
+    # THE DIAL IS THE SWITCH. A lane at zero slots is a lane that is off, and
+    # there is no second control saying so.
+    #
+    # Operator, 2026-09-23, on the card that had both: *"there's nothing to
+    # describe what 'auto' means or why their needs to be or should be on/off
+    # toggles. almost all of it always needs to run there's only one optional
+    # piece and it is killed by moving the 'cap' to zero."* They are right. Of
+    # four lanes, three must run for the application to work at all, so a
+    # switch beside each of them offered a choice that was never real — and
+    # for the one lane that IS optional, "off" and "zero slots" were two ways
+    # of saying the same thing that could disagree with each other.
+    #
+    # `enabled` stays in the model and on the API. It is still the mechanism:
+    # a disabled lane keeps its process and cancels its consumers, which is
+    # what makes it visible in the roster instead of looking like a crash. It
+    # is now DERIVED from the number the operator actually sets, rather than
+    # being a second thing for them to keep in agreement with it.
+    was_enabled = row.enabled
+    if enabled is not None:
+        new_enabled = enabled
+    elif slots is not None:
+        new_enabled = new_slots > 0
+    else:
+        new_enabled = row.enabled
+
     ceiling = derived_ceiling(lane)
     if new_cap < 0 or new_slots < 0:
         raise LaneUpdateRefused("slots and cap cannot be negative")
@@ -555,7 +579,11 @@ async def set_lane(
     await session.commit()
 
     applied, error = True, None
-    if enabled is not None:
+    # On the CHANGE, not on the field being present. Now that `enabled` is
+    # derived, every slots write would otherwise re-send a consumer command
+    # that changes nothing — the churn lesson #4183 keeps producing, arriving
+    # here through the new derivation.
+    if new_enabled != was_enabled:
         applied, error = await asyncio.to_thread(
             set_lane_enabled_sync, lane, new_enabled,
         )
@@ -567,13 +595,17 @@ async def set_lane(
     # HuggingFace for ~3.5GB, and rule 164 permits a runtime fetch only for a
     # feature that is optional and clearly OFF.
     #
-    # Only when the lane actually came on — `enabled is True` rather than
-    # `new_enabled`, so re-saving slots on an already-enabled lane does not
-    # re-enqueue. And only when the consumer change landed: enqueueing a task
-    # onto a queue nothing is consuming would leave it pending with no
-    # explanation until the lane returns.
+    # Only on the TRANSITION from off to on, so re-saving slots on a lane that
+    # is already running does not re-enqueue. This used to test `enabled is
+    # True` — the field having been sent — which stopped meaning "came on" the
+    # moment the dial became the switch: the UI no longer sends `enabled` at
+    # all, so the fetch that makes the ML lane usable would never have fired.
+    #
+    # And only when the consumer change landed: enqueueing onto a queue
+    # nothing is consuming would leave the task pending with no explanation
+    # until the lane returns.
     fetching = False
-    if enabled is True and lane.models and applied:
+    if new_enabled and not was_enabled and lane.models and applied:
         fetching = _enqueue_model_fetch()
 
     return {