Let the row refuse the write both kiosks were deciding in Python

Wave 1 of the remediation plan for the 2026-09-03 feature test run. Two kiosks,
one shape of defect, one critical consequence.

Both kiosks read the state, decided in Python, and then wrote. Nothing stops two
requests interleaving between the read and the write, so both see the same
pre-state and both proceed. Reproduced on MySQL 5.6 over HTTP, five concurrent
takes of 5 from a bin holding 5: all five were accepted and quantityonhand
landed on -20, because each request wrote its own arithmetic. The ledger had
recorded every one of them, so the cached quantity and the ledger disagreed
permanently, which is the number the shop floor actually reads. The USB kiosk
had the same shape: concurrent scans of one drive all succeeded and inserted
several open custody rows, so one drive was recorded out to two people and the
documented 409 never fired.

The comparison now lives in the WHERE clause, where the database settles it at
write time. printedparts._move_quantity issues
UPDATE ... WHERE quantityonhand >= :n and treats rowcount 0 as the refusal,
raising InsufficientStock, which take and adjust turn back into the message they
already gave - carrying the quantity the database holds now, not the stale one
the request read. The low-stock alert derives its before-value from what the
write produced for the same reason. Both USB paths claim the device with
ischeckedout (self-hosted) or status (external cmmc_usb) in the WHERE clause;
the external one claims BEFORE writing the log line, so a refused claim leaves
nothing to undo. Check-in is guarded the same way.

After the fix, the same five concurrent takes: one accepted, four refused,
quantityonhand 0 and the ledger sum 0.

Check-in also closes EVERY open row for the device rather than the newest.
One device can only be out once, so a second open row is corruption, and
closing only the newest left the older ones open forever - the device then read
as returned while its custody history said otherwise.

Separately, usbcheckouts now records who handed a drive back
(checkinsso/checkinname, migration usb0004checkinidentity). Returning for a
colleague is a supported flow that the kiosk asks to confirm, but the row it
wrote attributed the check-in to the HOLDER, so the custody history and the
audit report both named somebody who was not there. Nullable and deliberately
not backfilled: copying the holder's badge into old rows would manufacture
evidence for the exact claim this stops making.

Four tests. Both guards verified by planting: strip the condition out of either
UPDATE and its test fails.

Scope: product

plugins/usb/api/selfhosted.py

@@ -387,12 +387,34 @@ def kiosk_checkout(data):
             http_code=422)
 
     now = datetime.now(timezone.utc).replace(tzinfo=None)
+    # The transition IS the guard. The ischeckedout test above reads, decides
+    # in Python and then writes, so two kiosk scans of the same drive that
+    # interleave both read "available" and both insert a custody row - one
+    # drive recorded out to two people, and the documented 409 never fires.
+    # Making the flag part of the WHERE clause moves the decision into the
+    # write, where the database settles it: the second UPDATE matches no row.
+    claimed = USBDevice.query.filter(
+        USBDevice.usbdeviceid == device.usbdeviceid,
+        USBDevice.ischeckedout == False).update(
+            {USBDevice.ischeckedout: True,
+             USBDevice.currentuserid: badge,
+             USBDevice.currentusername: name,
+             USBDevice.currentcheckoutdate: now},
+            synchronize_session=False)
+    if not claimed:
+        db.session.rollback()
+        # Re-read the row rather than refreshing the object this request is
+        # holding: the whole point of arriving here is that the object is
+        # stale, and the caller deserves the name of whoever actually has it.
+        holder = db.session.query(USBDevice.currentusername).filter(
+            USBDevice.usbdeviceid == device.usbdeviceid).scalar()
+        return error_response(
+            ErrorCodes.CONFLICT,
+            'That device is already checked out{}'.format(
+                ' to {}'.format(holder) if holder else ''),
+            http_code=409)
     db.session.add(USBCheckout(usbdeviceid=device.usbdeviceid, sso=badge,
                                checkoutname=name, checkouttime=now))
-    device.ischeckedout = True
-    device.currentuserid = badge
-    device.currentusername = name
-    device.currentcheckoutdate = now
     db.session.commit()
     return success_response({'device_id': device.serialnumber,
                              'holdername': name},
@@ -439,15 +461,38 @@ def kiosk_checkin(data):
                          'holdername': device.currentusername or ''},
                 http_code=409)
 
-    open_checkout = (USBCheckout.query
-                     .filter_by(usbdeviceid=device.usbdeviceid, checkintime=None)
-                     .order_by(USBCheckout.checkouttime.desc()).first())
-    if open_checkout:
-        open_checkout.checkintime = datetime.now(timezone.utc).replace(tzinfo=None)
-    device.ischeckedout = False
-    device.currentuserid = None
-    device.currentusername = None
-    device.currentcheckoutdate = None
+    now = datetime.now(timezone.utc).replace(tzinfo=None)
+    # Guarded the same way as the checkout: only a device that is still out can
+    # be brought back, and the database decides that, not a Python read from
+    # earlier in this request.
+    released = USBDevice.query.filter(
+        USBDevice.usbdeviceid == device.usbdeviceid,
+        USBDevice.ischeckedout == True).update(
+            {USBDevice.ischeckedout: False,
+             USBDevice.currentuserid: None,
+             USBDevice.currentusername: None,
+             USBDevice.currentcheckoutdate: None},
+            synchronize_session=False)
+    if not released:
+        db.session.rollback()
+        return error_response(ErrorCodes.VALIDATION_ERROR,
+                              'That device is not checked out')
+
+    # EVERY open row, not just the newest. One device can only be out once, so
+    # a second open row is corruption - closing only the newest one left the
+    # older ones open forever, and the device then reads as returned while its
+    # custody history says otherwise.
+    #
+    # checkinsso/checkinname record WHO HANDED IT BACK, which is not always the
+    # holder: returning for a colleague is a supported flow, and attributing
+    # the check-in to the holder made the audit trail name somebody who was not
+    # there.
+    (USBCheckout.query
+     .filter_by(usbdeviceid=device.usbdeviceid, checkintime=None)
+     .update({USBCheckout.checkintime: now,
+              USBCheckout.checkinsso: badge,
+              USBCheckout.checkinname: name},
+             synchronize_session=False))
     db.session.commit()
     return success_response({'device_id': device.serialnumber},
                             message='{} checked in'.format(device.serialnumber))