"It works on my machine" is not a claim about configuration. It is a claim about history.
Production gets rebuilt from declared inputs: an image, a lockfile, migrations applied in order, config injected from the environment. Your machine did not get rebuilt. It accumulated. A migration that got applied, then hand-edited. A column you added in a psql session while debugging and did not write down. A dependency installed once to test an idea and left unpinned. Seed data shaped by months of manual clicking, so every row happens to have the optional field filled in.
Each of those is a decision that stayed out of any file. The code is identical, the substrate is not. That is why the failure looks absurd: the diff is empty and the behavior isn't.
The mechanic I watch for is anything that passes locally because of state rather than logic. Nullable fields that sit filled in your database. Enum values that exist in production and not in your seed. An ordering guarantee you inherited from the sequence of your own inserts rather than from a query.
So I stopped asking what's different about staging. I ask instead: can I destroy my local database, rebuild it from declared inputs only, and does the test still pass? When it doesn't, my machine is a cache of forgotten decisions and I have been testing against the cache.
I write up more of these failure patterns on my blog: https://polycratia.com/c/1feaa52c
Probably worth figuring out where your own local state drifts first: schema, seeds, dependencies...