fix(botfights): correct data_uid to 999 (actual image UID, not 1001)

The prior fix (5745db51) copied the fedimint-clientd/barkd data_uid
pattern (1001) without verifying it against this image. Live on
x250-beta the container still crash-looped with the same SqliteError:
unable to open database file — `podman exec botfights id` showed
uid=999(botfights) gid=999(botfights), not 1001. The image's
Dockerfile does `useradd --system` with no explicit UID, which lands
at 999, and security.user in the manifest is descriptive only — it is
not read by this app's (non-Quadlet) install path, so it can't be used
as the source of truth either.

Fixed data_uid to 999:999 and corrected security.user to 999 to match
reality. Verified live: manually re-chowned the existing bind mount to
999:999 on x250-beta, restarted the container, confirmed
`database migrated` + `listening on http://localhost:9100` +
`/api/health` returns ok, and confirmed /api/bots on x250-beta returns
identical data to the canonical arena (arena-proxy forwarding
correctly). Regenerated catalog; cargo test -p archipelago-container
manifest passes (38/38).

Co-Authored-By: Claude <noreply@anthropic.com>

apps/botfights/manifest.yml

@@ -19,15 +19,27 @@ app:
     secret_env:
       - key: JWT_SECRET
         secret_file: botfights-jwt-secret
-    # Matches security.user below. Was missing entirely (found live during a
+    # Was missing entirely (found live during a fresh install on a second
-    # fresh install on a second node): without it, the orchestrator's bind-dir
+    # node): without it, the orchestrator's bind-dir ownership fixup only
-    # ownership fixup only fires via a same-owner-as-anchor fallback that
+    # fires via a same-owner-as-anchor fallback that assumes an app with no
-    # assumes an app with no data_uid runs as container-internal root — but
+    # data_uid runs as container-internal root — but this app runs as a
-    # this app runs as 1001, not root, so that fallback doesn't apply either.
+    # non-root system user, so that fallback doesn't apply either. The bind
-    # The bind mount ended up unwritable, crash-looping the container on
+    # mount ended up unwritable, crash-looping the container on startup
-    # startup (SqliteError: unable to open database file). Same pattern as
+    # (SqliteError: unable to open database file). Same pattern as
     # apps/fedimint-clientd/manifest.yml and apps/barkd/manifest.yml.
-    data_uid: "1001:1001"
+    #
+    # 999, not 1001: the image's Dockerfile does `useradd --system` with no
+    # explicit UID, which lands at 999 (confirmed via `podman exec botfights
+    # id` — uid=999(botfights) gid=999(botfights)), not the security.user
+    # value below. security.user is not currently read by the non-Quadlet
+    # install path this app uses (only quadlet.rs consumes
+    # security.{capabilities,readonly_root,no_new_privileges,network_policy}
+    # for companion containers) — it's descriptive metadata here, not
+    # enforced. A first pass at this fix used 1001 (copying the
+    # fedimint-clientd/barkd pattern without verifying against this image)
+    # and still crash-looped; corrected after inspecting the running
+    # container's actual UID.
+    data_uid: "999:999"
 
   dependencies:
     - storage: 500Mi
@@ -41,7 +53,7 @@ app:
     capabilities: []
     readonly_root: true
     no_new_privileges: true
-    user: 1001
+    user: 999
     seccomp_profile: default
     network_policy: bridge
     apparmor_profile: default