manifests: umami -> 3.1.0 (v3 line) + filebrowser v2.63.13 with runAsUser:0

umami:
  Switch from SHA-pinned v3.0.3 to the tagged v3.1.0 release (the v3
  line proper -- same schema lineage, normal Prisma minor-version
  migration). This is the documented forward path that the version-
  checker hint `postgresql-latest -> 3.1` indicated. The v1.x
  postgresql-vX.Y.Z line we briefly tried earlier today is a
  DIFFERENT image lineage with incompatible migrations -- avoid.

filebrowser:
  Re-pin to v2.63.13 (debian-based default) so Renovate can track
  future bumps. The non-root UID in that image can't write to the
  existing PVC contents (chowned to root by the previous v2-alpine
  image), so set pod-level securityContext runAsUser:0 + runAsGroup:0
  to keep using the same volume layout without a chown initContainer.

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

manifests/umami.yaml

@@ -187,15 +187,7 @@ spec:
               cpu: "50m"
       containers:
         - name: umami
-          # NOTE: pinned to the exact image SHA the working 120d-old pod
-          # is on. v1.38.0 (the latest postgresql-vX.Y.Z) tries to apply
-          # migration `02_add_event_data` which requires an `event` table
-          # that this DB doesn't have -- the DB schema is older than v1
-          # numbered migrations expect. Until we plan a proper migration
-          # (likely to umami v3.x, which is what the dashboard `→ 3.1`
-          # hint suggests), this stays SHA-pinned so Renovate doesn't
-          # touch it and pod restarts don't roll the version forward.
-          image: ghcr.io/umami-software/umami@sha256:28f263fe06f79ebffa5a6a6e9bd33b7a278e9342a88e0bdac812416c9f9e4361
+          image: ghcr.io/umami-software/umami:3.1.0
           ports:
             - containerPort: 3000
           env: