This feels like a false choice as presented, but also there are different kinds of dependencies to consider which have a different "right" solution. That said, I can't think of a single case where either of your proposed solutions is the right one.
As you worded it, Service B cannot provide its output without an answer from Service A. That's a red flag to me right away, and tells me they probably shouldn't be separate microservices. It also means that in the current architecture, the only way to handle it is for Service B to talk directly to A and provide a composed response to the client through the API gateway, and in point of fact it also is a red flag that there probably shouldn't be two microservices. If that's true, then the output of B does not actually "depend on" A.
If what you meant was that the service endpoint exposed by the API Gateway is a composition of information from Services A and B, then that's your answer; each one is independent and gets composed by the Gateway.
If what you meant was that service A has data Service B needs (just data, not business logic), then another answer might be a shared data store (either a traditional database or a message queue or whatever) that both microservices talk to.
There's a pretty good discussion on the options and "why" of service composition over at Auth0 that you might find illuminating as well, and it also might help us create better answers for you is if you provided your specific business case rather than using generics like "Service A" and "Service B".
After Question Update
In the case of your updated use case, I would restructure your options depending on what other uses of those microservices exist. In no case that I can presently think of would I have the Selection microservice directly call the Placement microservice.
Instead, I would either compose the work in the API Gateway as you described, or consolidate the microservices into a single component.
Providing a unified, higher-level API that manages multiple service call upstream is well within their scope, imo. The main reason you might not want to do this is if there are technical limits to doing so, for example if there are a lot of chatty calls between the two microservices that need to happen to resolve one client request. That might be the case for example, if you wanted to provide a client service that optimizes "best fit" analysis, both of selecting the furniture and placing it and in doing so you need to select a piece and place it in many combinations. If that's the case, I'd consider making one "Room Design" microservice that handles all that internally, which may let you optimize the database and queries better and so on.