Migrate charterafrica builds to Docker Bake

[kelvinkipruto]

Description

Migrate charterafrica from the legacy shared root Dockerfile to the repository's per-app Dockerfile and Docker Bake build architecture, following the same pattern already established for climatemappedafrica/pesayetu/roboshield/techlabblog/trustlab.

Why

Docker builds against the legacy shared Dockerfile are slow and have repeatedly broken in ways unrelated to the app itself (see #1507, #1509). Moving charterafrica onto the turbo-prune-based Bake architecture keeps its build isolated, cacheable, and consistent with the other migrated apps.

charterafrica uses a custom Express + Payload server (server.ts, compiled to dist/server.js) that connects to MongoDB via payload.init() before next build runs, so — like climatemappedafrica — this build genuinely needs a reachable database, not just a well-formed connection string.

Neither of charterafrica's pre-bake deploy workflows (charterafrica-deploy-dev.yml, charterafrica-deploy-prod.yml) actually pushes to a real Dokku app today: DEV has no deploy step at all, and PROD's is gated behind an unresolved if: false TODO about which server to target. This migration preserves that exact state — it only replaces how the image is built, not what happens to it afterward.

What changed

charterafrica Docker Bake migration

• Add a pruned, multi-stage Dockerfile at docker/apps/charterafrica/Dockerfile. Like climatemappedafrica, this app doesn't use Next.js output: "standalone", so the runner stage copies the full node_modules/.next folder rather than a pruned standalone bundle, plus the app's own migrations/, scripts/, and app.json (Dokku cron config, not healthchecks — charterafrica runs scheduled jobs via scripts/ecosystem.mjs).
• Add the charterafrica target to docker-bake.hcl and the shared apps group, inheriting _app-runner. Unlike the Payload apps that inherit _payload-app-runner, charterafrica declares its own secret list, since its server reads PAYLOAD_SECRET_KEY (not PAYLOAD_SECRET).
• Standardize on DATABASE_URL for the Payload DB connection instead of MONGO_URL, matching roboshield/trustlab/climatemappedafrica, across payload.config.ts, migrate-mongo-config.js, turbo.json, and .env.template.
• Reuse the published ui-builder-base/ui-runner-base images in CI.
• Switch local make charterafrica and Compose usage to the Bake-built image.
• Mark charterafrica migrated in docker/README.md.
• Leave the legacy root Dockerfile stage untouched for now, matching the rollback-safety precedent from the other migrations.

CI/CD

• Add a reusable Bake workflow (_build-charterafrica.yml) and a new orchestration workflow (charterafrica.yml): build + push to DockerHub on every push to DEV (there's no DEV Dokku app to deploy to), and build on PROD version bump — deploy-dev/deploy-prod are added with if: false placeholders, mirroring the same unresolved TODOs already present in the legacy workflows this replaces.
• Add charterafrica to the pr-build.yml image-validation workflow and scripts/pr-build-targets.mjs's target detection. PR builds use the real CHARTERAFRICA_MONGO_URL secret (mapped to DATABASE_URL) rather than a dummy value, since the build needs a reachable database to succeed.
• No new GitHub secrets required — existing CHARTERAFRICA_MONGO_URL/CHARTERAFRICA_PAYLOAD_SECRET_KEY/CHARTERAFRICA_SENTRY_DSN/CHARTERAFRICA_SENTRY_PROJECT carry over, just remapped to the Bake secret names.

Validation

• docker buildx bake charterafrica against a real local MongoDB instance — full turbo prune → install → next build (compile, lint, static export) → payload build all pass.
• docker run smoke test — the built image boots, Payload connects, Next.js starts, and /admin returns HTTP 200.
• pnpm test:scripts — all pr-build-targets detection tests pass, including the updated charterafrica cases.
• ESLint passes on all changed files.

Type of change

• New feature (non-breaking change which adds functionality)

Screenshots

N/A

Checklist

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation