Deployed container doesn't match the image that was actually built (Dockerfile builder)

This is one of the more thoroughly-ruled-out reports I've seen on here — you've already eliminated stale bytecode, layer caching, CLI-vs-git-push deploy paths, and even verified via find / that only one clean copy exists in the built image. Given that, I don't think this is a requirements.txt/dependency issue at all anymore — worth pointing a couple of things at Railway directly rather than the app code:

1. Is this related to the active "Deployments slow to start" incident? Given the timing and the fact that your symptom is literally "the container serving traffic doesn't match what was built," this smells like it could be a builder→registry→deploy propagation issue — i.e. the deploy step pulling a stale/cached image reference instead of the one that was just verified clean. Worth asking Railway explicitly whether these are connected.
2. One thing not fully ruled out yet: if your Dockerfile uses a multi-stage build, it's worth double-checking that your build-time diagnostic (python3 -c "import charset_normalizer") runs in the exact same final stage that gets deployed — not an earlier builder stage whose output then gets COPY --from= into a final stage that could theoretically reuse a cached layer independently. Your cache-bust string proves the builder stage isn't cached, but if there's a separate final stage, that's a distinct cache domain.
3. A more direct way to prove it either way: instead of a build-time check, add the diagnostic to your actual runtime start command (or the very first line your app runs) — e.g. print pip freeze or hash the charset_normalizer package directory at container startup, right before the crash happens. If that output doesn't match what your build log showed, that's airtight proof the running container's filesystem differs from what was built — which is a Railway platform bug, not anything on your end. If Railway support sees that, it should be a fast escalation. This really does need someone with access to the builder/registry/deploy pipeline internals to confirm — but the runtime-hash test above would give you (and them) undeniable evidence either way.

Update: found the fix, thanks to your suggestion above.

Cause, confirmed by hashing every file in the package's install directory both at build time and at actual container startup: the .py source files matched byte-for-byte between build and runtime, but the running container also had extra compiled files (cd.so, md.so, md__mypyc.so, plus pycache/*.pyc I'd explicitly deleted during the build) that simply didn't exist anywhere in the built image. Something in the platform is injecting those on top of a correctly-built container, and the injected .so doesn't match the .py it expects — hence the AttributeError. Not fixable from the build side, since removing the package from the build entirely didn't stop the broken files from reappearing at runtime.

Fix: instead of fighting what's on disk, block the import at the Python level — sys.modules.setdefault("charset_normalizer", None) early in app startup. Python's import system treats a None entry in sys.modules as "block this module," so import charset_normalizer raises a clean ImportError without ever touching the filesystem, regardless of what gets injected there. requests already catches that ImportError internally and falls back to skipping automatic charset detection (which we don't need — every response we parse already declares its own encoding). Verified this works even with the package freshly installed and physically present on disk. Deployed and confirmed stable, serving real traffic now.

Thanks again for pointing me at the runtime-hash approach instead of build-time — that was the piece that actually cracked it.