Re: Same aggregate in 2 bounded contexts

Eric Evans and Vaughn Vernon explain quite well what bounded contexts should be. It would be good to have a look there, if you haven't already. 

 Basically the hierarchy is bounded contexts > modules > application services > domain services > infrastructure services
 

 In your situation I would keep only one bounded context with the supplier as an aggregate and the ftp connection details as a value object. Depending on your needs, the inventory could also be a value object. The supplier aggregate could have a method changeInventory($inventory) that replaces the old inventory value object with a new one. 
 

 I would have a command -> command handler as an application service called UpdateEnabledSuppliersInventory. This could be an empty DTO if you don't need any params. In the handler of this command you would deal with the transaction, security maybe, if it hasn't already been dealt with in the controller, getting the suppliers through the repository, calling a domain service SuppliersInventoryFetchService to fetch the inventories and saving the aggregates. 
 

 This domain service would be represented only by an interface in your domain with a method like fetch($supplierIds). In the infrastructure layer you would have its implementation, SuppliersInventoryFetchFromFTPService, that would connect to the ftp and return the inventories as integers.
 

 If there might be suppliers with different inventory fetching ways you could add another infrastructure service  and hide both behind a strategy based on the supplier type.