For posterity, this was the situation.
We have a few dropdown lists that are populated via information from the HTTPWebSession cache. Great. We also have an AJAX partial postback at one point during our work flow, because we have to do some server side validation of user input without screwing up everything on the screen. Still no problem.
The problem occurs when this partial postback returns, and attempts to use some CSS classes that link to images that no longer exist in our project. The images were moved. This returns 404s. You'd still think this isn't an issue as long as the code isn't actually USING these images. And it's not.
The PROBLEM is that, in our testing environments, a 404 is a 404. It simply returns that, no big deal. In our production environments, we redirect 404 errors to our login page, because it's a bad user experience and it's not good to implicitly reveal what does and doesn't exist. This is the environmental factor.
...Because we work in a high-security environment, the login page wipes the cache as part of its PreRender, so it doesn't matter if it was actually loading the page graphics or not. Ergo, an AJAX partial postback wiped the cache, which made the session-loaded information in the dropdown list -- which is not updated by the partial postback! -- not expected input. And, perfectly reasonably, Event Validation refused to accept this input on the full page submit.
This strange and complex problem was solved...by deleting a CSS class.