docs(ci): correct the app-image runner sizing rationale with measured numbers

The comment justified 16 vCPU by claiming both dominant steps scale with
cores. Only one does. Measured across two runs that restored the same
sticky-disk parent snapshot, so runner size was the only variable:

  [builder 5/6] next build      490.5s -> 143.9s  (3.4x)
  [deps 4/4]    bun install+gyp 465.3s -> 547.2s  (no gain)

The deps layer is a bun install plus a node-gyp rebuild pinned to JOBS=4
to avoid an OOM, so cores cannot help it.

This matters because end-to-end duration says the opposite. The deps layer
misses the Docker cache on nearly every run, and that ~500s swing swamps the
3.4x -- the one 16 vCPU sample (965s) lands mid-spread of the 8 vCPU samples
(766/778/1020/1167s), which reads as "no win" and invites a revert that would
throw away a real one. The miss is upstream: all five image builds share one
Blacksmith sticky disk (setup-docker-builder keys it on GITHUB_REPO_NAME
alone), so consecutive app builds restore the same parent snapshot and each
one's cache commit is discarded.

Comment-only; no behavior change.

Author: waleedlatif1

.github/workflows/ci.yml

@@ -159,12 +159,17 @@ jobs:
           # 16 GB one (exit 137). The others build in <5 min and idle at 12-15%
           # CPU on 8 vCPU, so they stay on the smaller tiers.
           #
-          # 16 vCPU on Blacksmith because this build is the critical path to a
-          # deploy — nothing ships until the image is pushed — and its two
-          # dominant steps both scale with cores (`bun install` ~300-400s, `next
-          # build` ~260s). The same `next build` runs on 16 vCPU in the separate
-          # Build App verification job, which does not gate anything; this one
-          # was doing comparable work on half the cores.
+          # 16 vCPU: this build gates every deploy, and `next build` scales with
+          # cores — 490.5s to 143.9s, measured across two runs that restored the
+          # same sticky-disk snapshot, so runner size was the only variable. The
+          # deps layer does not scale (465.3s to 547.2s): it is `bun install`
+          # plus a node-gyp rebuild pinned to JOBS=4. Size this on `next build`.
+          #
+          # Size it on step times, never end-to-end: deps misses the Docker cache
+          # on nearly every run, and that ~500s swing hides the 3.4x. All five
+          # image builds share one Blacksmith sticky disk (the action keys it on
+          # GITHUB_REPO_NAME alone), so consecutive app builds restore the same
+          # parent snapshot and each one's cache commit is discarded.
           - dockerfile: ./docker/app.Dockerfile
             ecr_repo_secret: ECR_APP
             gh_runner: linux-x64-8-core