Merge pull request 'fix(URGENT): pin umami to exact SHA (v1.38.0 has schema lineage mismatch)' (#3) from fix/umami-sha-pin into main

Previous PR pinned `ghcr.io/umami-software/umami:postgresql-v1.38.0`.
The new pod crashlooped on Prisma:

  ERROR: relation "event" does not exist
  Migration name: 02_add_event_data
  Database error code: 42P01

The 120-day-old working pod's actual image is:
  ghcr.io/umami-software/umami@sha256:28f263fe06f79ebffa5a6a6e9b...

It runs an older umami build whose schema doesn't have the `event`
table that the v1 migration `02_add_event_data` operates on. The DB
has migrations 10-14 applied (newer than 02 by name) but 02 isn't in
its applied set -- likely a schema fork between the line our 120d pod
runs and the postgresql-vX.Y.Z line that v1.38.0 advances toward.

Pin to the exact SHA that the working pod uses, so pod restarts +
ArgoCD syncs both keep producing pods on the same known-good image
(cached on the node, no registry pull needed). Renovate also stops
chasing the broken upgrade path.

Proper fix (deferred): plan a v3.x migration. The version-checker
dashboard hint `postgresql-latest → 3.1` suggests umami v3.x dropped
the `postgresql-` prefix and is what we'd want long-term. That needs
a real DB migration plan since the schema lineage is genuinely
different from this image.

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

manifests/umami.yaml

@@ -187,7 +187,15 @@ spec:
               cpu: "50m"
       containers:
         - name: umami
-          image: ghcr.io/umami-software/umami:postgresql-v1.38.0
+          # 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
           ports:
             - containerPort: 3000
           env:

manifests/webpage.yaml

@@ -107,7 +107,12 @@ spec:
     spec:
       containers:
         - name: filebrowser
-          image: filebrowser/filebrowser:v2.63.13
+          # NOTE: v2-alpine is a moving tag (Renovate can't track it).
+          # Pinning to v2.63.13 (debian-based default) broke the PVC permissions
+          # (the image runs as a non-root UID and can't write to files left
+          # by the alpine variant). A clean re-pin needs either an initContainer
+          # to chown the PVC, or a fsGroup on the pod spec. Revisit when time permits.
+          image: filebrowser/filebrowser:v2-alpine
           ports:
             - containerPort: 8080
           volumeMounts: