separate input/output on AppType

[haandev]

What is the problem this feature would solve?

Description

Elysia validates request bodies with Zod and exposes the parsed (output) type to handlers (z.infer).
Eden Treaty generates the client types from the exported App type, so it also receives only the output type.

For many APIs we need the raw input shape (the shape before Zod transforms/coercions) when building request payloads on the client side.
If the generated AppType stored both the Zod input and output types for each handler, Treaty could automatically provide:

handler.bodyInput – the raw JSON schema (e.g., string for z.string().datetime())
handler.bodyOutput – the parsed type the server receives (e.g., Date)
This would eliminate the need for manual “raw” type exports and make client‑side development smoother.

What is the feature you are proposing to solve the problem?

Expected behavior

For each route that defines a body (or params, query, etc.) with a Zod schema, the generated AppType should contain two properties:
type Route = {
// …other route info
bodyInput: z.input
bodyOutput: z.output
}

Eden Treaty’s client typings should expose both:
client..input – type to use when sending a request.
client..output – type returned by the server.
No breaking change for existing code – the current body type can remain as the output type for backward compatibility.
Motivation

Seamless integration – developers can construct request payloads with the exact shape the server expects before Zod’s transformations.
Reduced boilerplate – no need to manually export z.input types from the server.
Better type safety – the client cannot accidentally send a value that would be rejected by Zod’s parsing step.

What alternatives have you considered?

We are currently not using transforms on validation layer, since seems impossible.