Initiate a reverse-direction (inbound / return) train search scoped to an already-selected outbound fare and stream normalised solutions back as Server-Sent Events, using the same projection as POST /v1/trains/search. The stream ends with event: done; an empty result set completes cleanly with zero event: solution frames. Re-selecting a different outbound runs a fresh search.

An empty result is not attributable — the stream does not report why it is empty. In particular it does not separate the two cases a client most needs to tell apart: no inbound trains exist for the reverse itinerary, versus inbound trains exist but none combines with the selected outbound fare. No discriminating signal survives from upstream, so offer both recoveries rather than guessing which one applies — run a fresh outbound search (POST /v1/trains/search) to try different return dates, or have the traveler choose a different outbound fare and call this endpoint again.