Modeling a three-way association with optional relation
Using your Model #1, I believe the database itself can be made to enforce the stated constraints (i.e., a category and a product may only be related when they are both related to the same party) using the following constraints.


The primary key for category_party consists of category_id and party_id. This creates an optional many-to-many relationship between categories and parties. This implies the following.


A category is classified by zero-one-to-many parties.
A party classifies zero-one-to-many categories.

The primary key for product_party consists of product_id and party_id. This creates an optional many-to-many relationship between categories and parties. This implies the following.


A product is classified by zero-one-to-many parties. This will be overridden below to meet your stated requirements.
A party is classified by zero-one-to-many products.

There is unique constraint on product_id in the product_party. This makes the relationship between party and product a one-to-many instead of many-to-many. This implies the following. 


A product is classified by one-to-one party, overriding the previously-stated cardinality of this relationship.

The primary key of product_category_assignment consists of category_id, product_id and party_id. 
The foreign key from product_category_assignment to category_party consists of category_id and party_id
The foreign key from product_category_assignment to product_party consists of product_id and party_id
The constraint that a category and a product can only be related when they are related to a common party is enforced because product_category_assignment only contains one party_id which is used in both foreign key relationships.


I believe that the only requirement not covered here is that a product is required to have a related party (i.e., party is not optional).

Using Model #2 would require much more code (i.e., an ugly stored procedure?) to enforce the constraint because the structure of the database will allow the following. 


The category can be have one party_id (e.g., 1).
The product can have a different party_id (e.g., 2).
The product_category can have yet a third party_id (e.g., 3).


I do want to point out that there appear to be some unstated requirements here that could have some minor bearing on my answer above. For example...


What is the correct cardinality of the relationship between category and party? The two models you presented are different in this respect. 


Model #1 allows a category to be related to zero, one or many parties. 
Model #2 only allows for zero or one party for each category. 

Is a category required to have (at least) one party or is that relationship optional? This is not clear from your description or either of your models. 


I have always said that there are three things that are important in a data model: details, DeTaiLs and DETAILS. Sometimes nailing down the details of every relationship around the complexity can help you discover the best way to design the data model. Sometimes, complex relationships like this may point to missing entities (tables). Sometimes, complex requirements defy enforcement using only database structural constraints and require a bit of code (e.g., a stored procedure?) to finish the job.

Hope that helps.