Disable bytecode precompilation in the build -- widening the timeout wasn't enough

Locally, phonenumbers' largest generated geodata files (~900KB of literal
dict data) compile in ~0.1s each; the build host still timed out at 300s+
on a single one of the 29 such files -- a ~3000x gap no reasonable timeout
bump reliably survives across all of them. That gap points to something on
the build host itself (cross-arch emulation or memory pressure), not a file
that's merely slow. Turning bytecode compilation off trades a slow, flaky
build for a slower first import per container boot (--preload/prefork pay
that once, not per request) until the underlying host issue is found.

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

Dockerfile

@@ -33,7 +33,18 @@ RUN apt-get update && apt-get install --no-install-recommends -y git ca-certific
 
 COPY --from=ghcr.io/astral-sh/uv:latest /uv /usr/local/bin/uv
 
-ENV UV_COMPILE_BYTECODE=1 \
+# Bytecode precompilation is off, not just given a longer leash: locally,
+# phonenumbers' largest generated geodata/data*.py files (~900KB of literal
+# dict data each) compile in ~0.1s, but the build host needed 300s+ for a
+# single one of the 29 such files uv tried to compile here -- a ~3000x gap
+# that a bigger UV_COMPILE_BYTECODE_TIMEOUT can't fix, since 29 files at that
+# rate could still blow past any reasonable build budget. That gap points to
+# something on the host itself (cross-arch QEMU emulation or memory pressure
+# during the build), worth root-causing separately. Leaving bytecode
+# compilation off means each container pays a first-import cost instead
+# (--preload/prefork make that once per boot, not per request) -- slower
+# startup until the host issue is fixed, but a build that reliably finishes.
+ENV UV_COMPILE_BYTECODE=0 \
     UV_LINK_MODE=copy \
     UV_PYTHON_DOWNLOADS=never