55 handlers answer with an ORM entity, so eager relations are part of the response contract

[Danswar]

Measured in #4563.

The finding

55 handlers return an entity rather than a response object — PUT /userData/:id, GET /liquidityManagement/pipeline/in-progress, PUT /buyCrypto/:id/amlCheck among them, across 35 distinct entities. For those endpoints the eager relations declared on the entity are what the response contains.

Followed recursively, that closure covers 57 of the 103 eager relations the application builds at runtime.

Why it matters

• Eager relations cannot be reduced mechanically. Removing one changes what an endpoint returns — of 94 declarations, only 4 were both unread and outside every response.
• The response shape is defined by entity decorators, so a change made for persistence reasons is an API change.
• Adding eager: true to an entity in the closure silently widens the response of every endpoint returning it.

What keeps it a decision rather than a wall

All 55 carry a role guard and all but two are excluded from the Swagger schema, so the consumers are internal tooling rather than a published API.

Current guard

eager-relations.projection.spec.ts (in #4563) pins the closure and its total, and fails with the affected endpoints listed when a relation is added.

Open question

Whether those handlers should return DTOs instead. That decides how far the eager relations can be reduced, and it sits in front of the read-path work in docs/read-path-projections.md.