I think you want to go for a design of normalization within one Bounded Context. If one aggregate is a pure subset of the other (e.g. the product for cart is a subset of the product for product) I'd probably use a single table. Otherwise, I'd probably use a second table that refers to the first table rather than duplicating columns between two tables.
For what it's worth, I'm not convinced that the two different product items you're describing are both aggregates. One or both may be merely entities or value objects; perhaps there really is only one product aggregate in this BC.
Update
Based on your diagram: in the cart domain, you want a collection of references to products (by Product ID). I wouldn't even call that collection a product table, but instead I'd call that a cart item table. This cart item table would have fields relevant to cart items, such as: the cart table item id, a product table foreign key reference, maybe along with things applicable to cart'ing but not products, like say, a count of the number of this product item being ordered, and even timestamp of when added to the cart (price at the time added to the cart, etc...).
I wouldn't duplicate any product table columns in the cart item table. When you need a product item column value (such as description), you use a join from the cart item table to get it.
(If/when you find that for performance reasons you want to start making these more independent, then it is worth starting to think of these as different bounded contexts, because decoupling these things for performance introduces new (consistency management) responsibilities. In between two different contexts, you can use translation, duplication & caching, and eventing, as necessary when you might run multiple databases for performance.)
ProductIdof the Product entity in theListingBC.