React query feature

[RejectKid]

Summary

Adds TanStack Query generation to ZibStack.NET.TypeGen.

This introduces TypeTarget.TanStackQuery plus fluent TanStackQuerySettings, then emits typed TanStack Query v5 client code from TypeGen’s discovered endpoint model. Generated output includes fetch functions, query keys, queryOptions, mutationOptions, React hooks, prefetch helpers, and invalidation helpers.

The endpoint model now also reads Minimal API .WithName(...) and .WithTags(...), so generated operation names and query-key groups can be controlled from normal Minimal API metadata.

Also adds docs and a richer SampleApi workflow showing Minimal API + generated TanStack Query output.

Lemme know how you feel about this? some team members were asking if zib could have this feature

Affected package(s)

• ZibStack.NET.TypeGen
• ZibStack.NET.TypeGen.Abstractions
• docs
• packages/ZibStack.NET.TypeGen/sample/SampleApi

Type of change

• Bug fix
• New feature
• Generator / generated-code behavior change
• Analyzer / diagnostic change
• Docs only
• Build / tooling

How was this verified?

Added/updated tests for:

• TanStack Query emitter output
• Fluent TanStackQuery(...) configuration parsing
• Minimal API .WithName(...) / .WithTags(...) endpoint metadata
• SampleApi generated api.gen.ts output

Commands run:

dotnet build packages/ZibStack.NET.TypeGen/src/ZibStack.NET.TypeGen/ZibStack.NET.TypeGen.csproj
dotnet build packages/ZibStack.NET.TypeGen/tests/ZibStack.NET.TypeGen.Tests/ZibStack.NET.TypeGen.Tests.csproj
dotnet build packages/ZibStack.NET.TypeGen/sample/SampleApi/SampleApi.csproj -c Release --nologo
dotnet test packages/ZibStack.NET.TypeGen/tests/ZibStack.NET.TypeGen.Tests/ZibStack.NET.TypeGen.Tests.csproj --no-build -v normal

[MistyKuu]

Nice work on this - read well. Clean split (client only, models stay in the TS emitter), sensible defaults, and good test coverage. A few things I'd sort before merge:

1. Docs contradict the code on .Produces<T>() (the only one that really matters)
This PR adds reading of .Produces<T>() (ResolveChainedProducesResponseType -> endpoint.ResponseCSharpType = producedResponseType), but at the same time endpoint-discovery.md says ".Produces<T>() aren't read yet". They are now - please update the docs.

Minor stuff, take it or leave it:

• Produces<T> runs after the lambda return type is set, so a lambda with a concrete return + .Produces<T>() will resolve to the Produces type. That changes OpenAPI output too - probably intended, but worth a conscious confirmation.
• EnsureTypeScriptNames recomputes type names from scratch instead of reading EmittedName from the TS pipeline. If the TS emitter does any dedup this copy doesn't replicate, model imports in api.gen.ts could point at a different name. Not a confirmed bug, but duplicating the naming rules is a maintenance risk.
• decimal -> string - fine if the TS emitter maps it the same way; if it maps to number, param types will diverge from the models.
• new URL(path, VITE_API_URL) throws when the env var is undefined. The sample sidesteps it with window.location.origin - a one-line note in the docs would help.
• An unbound route param renders String(undefined) in the path (literal "undefined"). Method-group edge case, but maybe worth a diagnostic.
• Two empty test commits - squash on merge.

Overall good to go after #1.

[RejectKid]

Nice work on this - read well. Clean split (client only, models stay in the TS emitter), sensible defaults, and good test coverage. A few things I'd sort before merge:

1. Docs contradict the code on .Produces<T>() (the only one that really matters) This PR adds reading of .Produces<T>() (ResolveChainedProducesResponseType -> endpoint.ResponseCSharpType = producedResponseType), but at the same time endpoint-discovery.md says ".Produces<T>() aren't read yet". They are now - please update the docs.

Minor stuff, take it or leave it:

• Produces<T> runs after the lambda return type is set, so a lambda with a concrete return + .Produces<T>() will resolve to the Produces type. That changes OpenAPI output too - probably intended, but worth a conscious confirmation.
• EnsureTypeScriptNames recomputes type names from scratch instead of reading EmittedName from the TS pipeline. If the TS emitter does any dedup this copy doesn't replicate, model imports in api.gen.ts could point at a different name. Not a confirmed bug, but duplicating the naming rules is a maintenance risk.
• decimal -> string - fine if the TS emitter maps it the same way; if it maps to number, param types will diverge from the models.
• new URL(path, VITE_API_URL) throws when the env var is undefined. The sample sidesteps it with window.location.origin - a one-line note in the docs would help.
• An unbound route param renders String(undefined) in the path (literal "undefined"). Method-group edge case, but maybe worth a diagnostic.
• Two empty test commits - squash on merge.

Overall good to go after #1.

Alrighty how's this feeling?