{Analysis} Exploration in the purpose of potential split.

[Kakudou]

The purpose of this investigation is to figure out whether client-python has become a beast doing too many jobs at once, and whether it should be split into two cleaner parts:

• a real client, responsible only for interacting with OAEV
• a core-sdk, responsible for the shared base classes, helper logic, and runtime validation used by injectors and collectors

Right now, client-python appears to mix pure client responsibilities with reusable framework logic.
That kind of overlap is how codebases turn into sludge over time.
The goal of this split is to cut those concerns apart cleanly, make the shared logic reusable on purpose instead of by accident, and give the architecture a shape that is easier to maintain, extend, and reason about.

This deep dive should stay pragmatic and focus on:

• the effort required to implement the split
• the technical and architectural complexity involved
• the feasibility of extracting shared logic into a dedicated core-sdk
• the expected gains in clarity, reusability, and maintainability
• the migration impact on existing code and usage
• the main risks and trade-offs introduced by the change

The expected outcome is a clear recommendation:
whether this split is actually worth doing, and if it is, what the most practical target structure should be.