fix(deploy): raise instance class to F4_1G to stop OOM instance churn

Production ran gunicorn -w 8 on an F4 (1 GB) instance. Eight workers each
importing the full stack (sqlalchemy + geoalchemy2 + shapely + cloud-sql
connector + pygeoapi) exceeded 1 GB, so App Engine terminated processes for
"using too much memory" ~44x per 3h and cycled workers continuously (304
"Booting worker", 297 SIGTERM in a 3h window). With the single min-instance
constantly reborn, every request hit a booting instance and re-cold-loaded
the app -- site-wide degraded latency even at low traffic.

Raise instance_class F4 -> F4_1G (2 GB) so the eight workers fit, per App
Engine's own "consider a larger instance class" guidance. Keeps the -w 8 /
max_concurrent_requests: 6 scale-out tuning from the prior starvation fix
intact. Template is shared; staging/testing (-w 4, scale-to-zero) gain
harmless headroom at negligible idle cost.

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

Author: jirhiker

.github/app.template.yaml

@@ -2,7 +2,12 @@ service: ${SERVICE_NAME}
 runtime: python313
 entrypoint: ${ENTRYPOINT}
 service_account: "${CLOUD_SQL_USER}.gserviceaccount.com"
-instance_class: F4
+# F4_1G (2 GB) not F4 (1 GB): the entrypoint runs gunicorn -w 8, and eight
+# workers each importing the full stack (sqlalchemy + geoalchemy2 + shapely +
+# cloud-sql connector + pygeoapi) exceeded 1 GB. App Engine logged "using too
+# much memory and was terminated" ~44x/3h and cycled workers continuously
+# (304 "Booting worker", 297 SIGTERM in 3h), so every request re-cold-loaded.
+instance_class: F4_1G
 inbound_services:
   - warmup
 automatic_scaling: