There is no reason in this case to include the type table in the query. There is only one field in the table other than the PK therefore, the form's combo will show the only field in the lookup table anyway. When you include the lookup table in the query, it is because there are multiple data columns you want to display and the combo box can only show one of them.
The RecordSource query would work fine with the join but ONLY if you select the correct column. You need to bind the Type_ID in the Customers table to the combo, NOT the PK from the Customer_Type table. Your form is NOT changing the Type_ID in the type table, it is changing the type_ID (Foreign key) in the Customers table. When you join tables in a query, you always select the FK half of the pair, not the PK half. You NEVER need to select both and selecting both just leads to confusion.
If you are creating a RecordSource query for a report rather than the form, then, it makes sense to include the lookup table with a join so you can display the lookup value using a textbox rather than a combo. On a form, you are displaying the lookup value using a combo so there is no need to join to the lookup table in the RecordSource query.
I disagree with June regarding naming standards. It is much easier to see the relationships if both the PK and the FK have the same name whenever possible (they can't always). If you prefer them to be different, an acceptable solution is to suffix the FK with "_FK". So the name in Customer_Type would be Type_ID and the name in Customers would be Type_ID_FK.
I know it all seemed easier when you were using table level lookups, but once you understand the concept of the combo/listbox, you'll be better off without the table level lookups.