fix(ci): docker-publish reliability — separate cache scope per ref + 30min timeout

The v1.4.14 release exposed a hard hang: the `main` push and the
`v1.4.14` tag push both fired at SHA `e5fae9bce6cb` simultaneously.
The tag run finished cleanly in 17 minutes; the main run sat on
`#26 [linux/amd64 runner 2/14] RUN apk add tzdata` from 16:14:52Z
until Marc cancelled it at 17:00:15Z — 47 minutes of zero buildkit
output. Same SHA, same Dockerfile, same runner image, vastly
different outcome.

Root cause: both `cache-from: type=gha` and `cache-to: type=gha,mode=max`
used buildx's default scope name (`buildkit`). With `mode=max` every
stage of every platform is exported to the cache; the two concurrent
writers raced on the gha cache manifest and one deadlocked on the
exporter. This is the classic "shared buildkit cache between
parallel refs" failure mode — pinned down by the symmetry of
"same SHA, parallel runs, only the slower-to-arrive one hangs".

Fix is two layers:

1. Per-ref cache scope (`scope=build-${{ github.ref_name }}`). Each
   workflow invocation now writes to its own slot:
   - `build-main` for branch pushes
   - `build-v1.4.x` for tag pushes
   - `build-pr-N` for pull-request pushes
   `cache-from` reads BOTH the ref-specific scope AND `build-main`,
   so a tag built right after a main push still reuses main's
   layers — just without contending on the writer side.

2. Job-level `timeout-minutes: 30`. The fastest healthy build of the
   v1.4.7..v1.4.13 series finished in 12 min, the slowest in 18 min.
   30 min covers a slow exporter while still rescuing the runner
   automatically if buildkit deadlocks again, instead of waiting for
   a human to notice and click Cancel an hour later.

Pass-rate impact in the v1.4.15 marathon: 30/60 successes over
30 days (most "cancelled" entries are by-design — concurrency group
cancels superseded runs — but the v1.4.14 hang counts as a
preventable outlier). After this commit a deadlocked run is bounded
to 30 min and a release commit's two refs no longer fight each other.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

.github/workflows/docker-publish.yml

@@ -21,6 +21,14 @@ jobs:
   build-and-push:
     name: Build & push multi-arch image
     runs-on: ubuntu-latest
+    # 30 min wall clock — a healthy multi-arch build finishes inside 17 min
+    # (see v1.4.7..v1.4.13 history). The v1.4.14 main run hung 47 min on
+    # `[linux/amd64 runner 2/14]` before Marc cancelled because tag + branch
+    # were exporting to the same gha cache scope concurrently (see fix below).
+    # 30 min is enough for a clean build + a slow exporter, while still
+    # rescuing the runner if buildkit deadlocks instead of waiting for a
+    # human to notice.
+    timeout-minutes: 30
     permissions:
       contents: read
       packages: write
@@ -63,6 +71,23 @@ jobs:
             org.opencontainers.image.licenses=AGPL-3.0-only
             org.opencontainers.image.source=https://github.com/${{ github.repository }}
 
+      # Per-ref gha cache scope: previously both `cache-from: type=gha` and
+      # `cache-to: type=gha,mode=max` used buildx's default scope name
+      # (`buildkit`). When a release commit lands, GitHub fires the workflow
+      # twice in parallel — once for the `main` push, once for the `v*` tag
+      # — both pointed at the same SHA, both writing to the same gha cache
+      # key. mode=max exports every stage of every platform; the concurrent
+      # writers race on the cache manifest and one deadlocks. The v1.4.14
+      # main run sat on `[linux/amd64 runner 2/14] RUN apk add tzdata` for
+      # 47 minutes (cancelled by hand) while the tag run on the same SHA
+      # finished cleanly in 17 minutes — clear smoking-gun.
+      #
+      # Splitting the scope by `github.ref_name` (e.g. `main`, `v1.4.15`,
+      # `pr-123`) gives each invocation its own cache slot. We `cache-from`
+      # both the ref-specific scope AND the canonical `main` scope so:
+      #   - feature branches/tags can warm-start off main's last good build
+      #   - a tag built right after a main push hits main's cache for layer
+      #     reuse without contending on writes
       - name: Build & push image
         uses: docker/build-push-action@v6
         with:
@@ -72,7 +97,9 @@ jobs:
           push: ${{ github.event_name != 'pull_request' }}
           tags: ${{ steps.meta.outputs.tags }}
           labels: ${{ steps.meta.outputs.labels }}
-          cache-from: type=gha
-          cache-to: type=gha,mode=max
+          cache-from: |
+            type=gha,scope=build-${{ github.ref_name }}
+            type=gha,scope=build-main
+          cache-to: type=gha,mode=max,scope=build-${{ github.ref_name }}
           provenance: true
           sbom: true

src/components/admin/user-management-section.tsx

@@ -315,9 +315,7 @@ export function UserManagementSection() {
                         {u.role}
                       </Badge>
                     </td>
-                    <td className="px-3 py-2 text-center">
-                      {u.passkeyCount}
-                    </td>
+                    <td className="px-3 py-2 text-center">{u.passkeyCount}</td>
                     <td className="text-muted-foreground px-3 py-2 text-right text-xs whitespace-nowrap">
                       {formatDate(u.createdAt)}
                     </td>