Indeed my comment about using table_query is not good because it will require for the database to scan all the moves which is not good for a growing table like stock_move. But also the current proposal as the same problem by joining the table with itself.
In fact it is better to compute the downward and upward traces in Python just for the displayed moves.
Here is review387871002 which implement a new model based on stock.move and compute the downward and upward traces. The benefit is that it works also if production is not activated (and replace the existing moves relate). And thanks to the contextual menu, user can follow the trace for a specific lot from a production.
By the way I did not implement a scenario because the code is mainly about definition of model which is executed by the standard module test case.

Here is review381061002 implementing it.
It still missing some test suite and minor fixes but all the functionality is there

Following: https://discuss.tryton.org/t/view-lot-traceability/4590