fix(ci): revert to GHCR - GitLab's own registry never got past step 1

GitLab's Container Registry was enabled at the omnibus service level
(registry.gitlab.vnc.biz responds, confirmed with a real GitLab-shaped
401), but the pipeline's build job kept trying to auth against Docker
Hub instead - CI_REGISTRY was empty. Root cause: registry_external_url
only starts the registry SERVICE; gitlab_rails['registry_enabled'] = true
is a separate key that tells the Rails app the registry exists, and it
was never set. Symptom matched exactly: registry reachable, but no
Container Registry toggle anywhere in project settings OR admin settings,
and CI_REGISTRY empty in every job regardless of retry.

Reverting the pipeline to ghcr.io/brvncde-dotcom/vncmail-plus-dev - the
exact image the sandbox was already running before any of this session's
pipeline existed, confirmed public (no imagePullSecrets needed). This is
a revert to a known-working path, not a new risk.

Needs $GITLAB_CI_GHCR_TOKEN (GitHub PAT, write:packages) and
$GITLAB_CI_GHCR_USER as masked/protected CI/CD variables - a GitHub
credential has to come from GitHub, nothing on the GitLab side can
substitute for it.

.gitlab-ci.yml

@@ -36,7 +36,13 @@
 #
 # Prerequisite this file assumes (documented in VNCMAIL-SETUP.md, not
 # something this file can set up itself):
-#   - GitLab Container Registry enabled for this project (confirmed done).
+#   - A GitHub PAT (write:packages) for ghcr.io/brvncde-dotcom as
+#     $GITLAB_CI_GHCR_TOKEN, plus the matching GitHub username as
+#     $GITLAB_CI_GHCR_USER — both masked/protected CI/CD variables.
+#     GitLab's own Container Registry was tried first (registry_external_url
+#     alone isn't enough - gitlab_rails['registry_enabled'] = true is a
+#     separate config key that never got set, so CI_REGISTRY stayed empty);
+#     revisit switching back once that's actually confirmed working.
 #   - A GitLab Runner (any kind — no cluster access needed at all now).
 #   - Either "allow this job token to push to this project" enabled
 #     (Settings → CI/CD → Job token permissions), OR a project access token
@@ -54,7 +60,17 @@ stages:
   - bump-prod
 
 variables:
-  IMAGE: $CI_REGISTRY_IMAGE/vncmail-plus
+  # Reverted to GHCR 2026-08-05: GitLab's own Container Registry never made
+  # it past "the registry service responds" - the Rails app itself never
+  # picked it up (no project-settings toggle appeared, CI_REGISTRY stayed
+  # empty even after the omnibus registry_external_url config), most likely
+  # because gitlab_rails['registry_enabled'] = true was never separately
+  # set. That's a second, distinct config key from registry_external_url -
+  # revisit switching back once/if that's actually confirmed on the server.
+  # Same image name the sandbox already ran before this pipeline existed
+  # (confirmed public - no imagePullSecrets needed, see
+  # base/deployment.yaml's history), so this is a revert, not a new risk.
+  IMAGE: ghcr.io/brvncde-dotcom/vncmail-plus-dev
   GIT_STRATEGY: clone
 
 # ---------------------------------------------------------------------------
@@ -86,7 +102,11 @@ build:
   rules:
     - if: '$CI_PIPELINE_SOURCE == "push" && $CI_COMMIT_BRANCH == "dev"'
   before_script:
-    - echo "$CI_REGISTRY_PASSWORD" | docker login -u "$CI_REGISTRY_USER" "$CI_REGISTRY" --password-stdin
+    # GHCR needs a real GitHub PAT (write:packages) as GITLAB_CI_GHCR_TOKEN,
+    # plus GITLAB_CI_GHCR_USER (the GitHub username the PAT belongs to) —
+    # both as masked/protected CI/CD variables. Nothing GitLab-native can
+    # substitute here; a GitHub credential has to come from GitHub.
+    - echo "$GITLAB_CI_GHCR_TOKEN" | docker login ghcr.io -u "$GITLAB_CI_GHCR_USER" --password-stdin
   script:
     - docker build --build-arg GIT_COMMIT=$CI_COMMIT_SHA -t "$IMAGE:sha-$CI_COMMIT_SHORT_SHA" -t "$IMAGE:dev-latest" .
     - docker push "$IMAGE:sha-$CI_COMMIT_SHORT_SHA"