Feature request: configurable return shape on @kubb/plugin-axios

[kneekeel]

Summary

v4's @kubb/plugin-client had this via dataReturnType: 'data' | 'full'. v5 removed it when
splitting plugin-client into pluginAxios/pluginFetch behind the shared RequestResult
contract (migration guide).
Request: reintroduce an equivalent on pluginAxios — a client.returnType: 'full' | 'data'
option so a generated operation's promise can resolve directly to data instead of the full
{ status, data, error, contentType, request, response } object.

Motivation

• Default throwOnError: true means every resolved promise is already a success —
  status/error/contentType/request/response add no information the caller doesn't
  already have.
• Every call site writes result.data / destructures { data } to reach the one field that
  actually varies.
• No option today makes the call resolve directly to the body. Workarounds: a hand-rolled
  unwrap() per call site, or patching the generated .kubb/client.ts (copied verbatim from
  templates/axios.ts, not owned by the consumer) — fragile against template changes.

Proposed API

pluginAxios({
  client: {
    returnType: 'full' | 'data', // default: 'full' (unchanged)
  },
})

• 'full' (default): unchanged.
• 'data': resolves directly to success data when throwOnError: true. Under
  throwOnError: false, stays full in both branches — data alone can't distinguish
  success/failure once errors stop throwing.
• Type-level: ThrowOnError extends true branch → DataOf<SuccessOf<TResponses>> instead of
  SuccessResultUnion<...> (both already exist internally in templates/axios.ts).

// returnType: 'data'
const invoice = await postInvoiceRequest({ body }); // PostInvoiceRequestResponse directly

// returnType: 'full' (default)
const invoice = (await postInvoiceRequest({ body })).data;

Alternatives considered

• Duplicate per-operation export (postInvoiceRequestData) — doubles the generated surface,
  default stays noisy.
• Ship unwrap() as a runtime helper — opt-in per call, not a package-wide default.

Backwards compatibility

Fully opt-in; default ('full') unchanged. Only consumers setting returnType: 'data' are
affected.

Open questions

• Why was dataReturnType mandated for removal in v5 rather than carried onto
  pluginAxios/pluginFetch? Tied to the shared RequestResult contract's design
  (type-inference cost, ambiguity under throwOnError: false), or purely a scope call during the
  plugin-client split with no objection to a narrower version returning?
• Naming: returnType vs. dataOnly / unwrap / resultShape.
• Should 'data' also apply under sdk: true (class-based output)?
• Does this belong on pluginAxios directly, or a shared base option other transport plugins
  could reuse?