fix(backup): release the SQLite writer before the K-profile MQTT phase (#2656)

_apply ran archives and spools first, which autoflushes their INSERTs and so
opens SQLite's single write transaction, then called _restore_kprofiles —
which awaits get_kprofiles per printer per nozzle at timeout=5.0 with
max_retries=3, i.e. up to ~15 s each against a printer that ignores the
request. The commit only came afterwards, in run_restore. busy_timeout is 15 s
(core/database.py:21), so a restore covering a couple of unresponsive printers
held the writer past it and unrelated writes elsewhere in the app failed with
"database is locked".

Commit the database categories before the MQTT phase starts. The K-profile
work is not in that transaction anyway — it leaves over MQTT — so the only
thing lost is rolling those categories back when a K-profile send fails, and
that rollback was never the right behaviour: extrusion_cali_set has already
reached the printer by then, so undoing the database half would just make the
two disagree.

backend/app/services/github_restore.py

@@ -429,6 +429,10 @@ class GitHubRestoreService:
                     }
 
                 except Exception as e:
+                    # Rolls back whatever is still uncommitted. That is every
+                    # database category unless K-profiles were also selected, in
+                    # which case _apply has already committed them before talking
+                    # to the printers — see the comment there.
                     logger.exception("Restore failed for config %s ref %s", config_id, resolved)
                     await db.rollback()
                     log.status = "failed"
@@ -513,6 +517,23 @@ class GitHubRestoreService:
 
         # Last, because it leaves the database and publishes over MQTT.
         if RestoreCategory.KPROFILES in categories:
+            # Commit the database categories FIRST, and not just for tidiness.
+            # Everything above has already autoflushed its INSERTs, so SQLite is
+            # holding the single write transaction — and _restore_kprofiles then
+            # awaits get_kprofiles per printer per nozzle, which is
+            # timeout=5.0 * max_retries=3, i.e. up to ~15 s each against an
+            # unresponsive printer. busy_timeout is 15 s (core/database.py), so a
+            # farm with a couple of sulking printers would hold the writer past
+            # it and every concurrent writer in the app would fail with
+            # "database is locked".
+            #
+            # The cost is that a K-profile failure no longer rolls back the
+            # categories that already succeeded. That is the correct trade
+            # anyway: extrusion_cali_set has left for the printer by then and
+            # cannot be rolled back either, so a rollback would only have made
+            # the database disagree with the hardware.
+            await db.commit()
+
             self._progress = "Sending K-profiles to printers..."
             tally = _CategoryTally()
             await self._restore_kprofiles(db, payload, tally)