Normalize shape key generation from where clause

A user spent several days trying to debug why a big shape was frequently getting recreated (409s) when they were navigating around the app and doing other actions. They weren't doing any of the normal things that trigger 409s it seemed like changing the shape def in their proxy or pushing schema updates to their db.

After adding lots of logging to the URLs generated in their proxy, they eventually noticed that under certain conditions, the order of the `where in` clauses changed, triggering Electric to think it's a new shape and return a 409 to force a reload of the shape.

This was both a very noticeable performance problem w/ their app and a head-scratcher to debug.

We should prevent this issue by normalizing all non-essential parts of the where clauses. I assume we do some already but sorting where in & array operations makes sense. I had Claude come up with a long list of other potential ways to normalize https://claude.ai/share/3230d2fa-95fb-40ed-9565-d50471c44698