Enforce component-level #include paths everywhere

Some ORE Studio source files include sibling headers with a bare relative path (e.g. #include "process_factory.hpp" or #include "processes/gmm_process.hpp") instead of the project convention of always starting from the component root (e.g. #include "ores.analytics.quant/service/process_factory.hpp"). Observed while moving code out of ores.synthetic/service/src (task in story Extract stochastic process math from ores.synthetic into ores.analytics.quant): feed_controller.hpp, simulate_handler.hpp, and the pre-move process_factory.cpp all used bare relative includes. Audit the wider codebase for the same pattern and fix it, and consider whether a clang-tidy check or a simple grep-based CI lint could catch regressions (a relative include silently breaks when the including file moves, whereas a component-level include fails loudly at the call site that needs fixing).

Relative includes make a header's dependencies invisible from the `#include` line alone (you can't tell what component a bare processes/gmm_process.hpp belongs to without opening the file), and they silently keep compiling after a file is moved to a different directory within the same component – exactly the kind of drift that should fail loudly instead. Component-level includes are the project-wide convention judging by the bulk of the codebase; the relative-include files are the exception, not a deliberate alternative style.

• Fixed as part of the move: ores.synthetic/service/src/feed_controller.hpp, ores.synthetic/service/src/simulate_handler.hpp.

• Story: Extract stochastic process math from ores.synthetic into ores.analytics.quant