I at last understood what was going on. One of the "problem" tables was just a result of my incorrect grasp of how Entity Framework works, not a real issue. With just two columns, this table was a pure join table, with one column referring to table A and the other to table B. A pure join table does not have a class created by Entity Framework. The only thing it does instead is turn it into navigation links for the classes of the two connected tables (class A and class B).
The mismatched column definitions in the database were the true source of the issue with the second table. A column of type NUMBER(18) and a column of type NUMBER(22) were present in a foreign key definition. NUMBER(18) and NUMBER(22) were being converted by EF to long and decimal, respectively. Different C# types on the endpoints of EF's navigation links seem to be a bad thing.
I changed my EDM number mapping (see https://docs.oracle.com/cd/E56485_01/win.121/e55744/entityDataTypeMapping.htm#BABGBJCI) to make NUMBER(18) and NUMBER(22) both resolve too long in order to fix the issue. In order for all of my field types to regenerate, I then deleted all of my table definitions from the EF Designer and added them back. Although I'm sure I could have fixed the database's mismatched types, I chose the code approach after discovering the issue in a few dozen more locations.