…stently (v3.18.1)

When an endpoint is a proxy, all server-filled parameters now forward to
the upstream through one unified path: user claims, IP address, HTTP
Custom Type fields, and resolved-parameter expressions.

Placement mirrors the endpoint's own signature, NOT the HTTP verb:
- a @body_parameter_name param carries the raw request body;
- otherwise RequestParamType decides — QueryString appends to the proxy
  query string, BodyJson merges into the proxy JSON body (typed:
  numbers / booleans / embedded json / strings) when the method carries
  a body.

Additive: the verbatim incoming request is still forwarded; the
automatic params are added on top so the upstream receives the same
parameter set the routine would.

The previous claim/IP-only query append in BuildTargetUrl is removed and
folded into the unified mechanism. Behavior change: claims/IP now follow
RequestParamType (unchanged for GET/QueryString — still query; for
BodyJson endpoints they now go to the body).

Notes: body merge only for JSON content types (multipart/non-JSON
forwarded verbatim); only expanded per-field HTTP-type params forwarded.

Tests cover GET-query, POST-body (typed), param_type-query on POST, and
resolved-param forwarding; existing claim/IP proxy tests pass unchanged.
Full suite green (2288). See changelog/v3.18.1.md.

Also adds a Claude Code skill bundle (.claude/skills/npgsqlrest/) — a usage
guide plus full annotation and configuration references generated from
--annotations/--config — and a README section on installing it.

…er_name by any param name

Two fixes for proxy endpoints that forward auto-filled parameters (v3.18.1),
surfaced by combining @Proxy with an HTTP Custom Type parameter.

- ProxyOptions.MaxForwardedQueryParamLength (default 2048): a server-filled
  value longer than the limit is skipped with a warning instead of being
  percent-encoded into the upstream query string, which overflowed the request
  line (HTTP 414/431 / connection reset). Wired through Builder, ConfigDefaults,
  ConfigSchemaGenerator, ConfigTemplate, and appsettings.json.

- @body_parameter_name now matches case-insensitively and accepts any of a
  parameter's names. For an HTTP Custom Type field expanded from a composite,
  the converted name (responseBody), the expanded signature name
  (_response_body, via the new NpgsqlRestParameter.ExpandedName alias), and the
  shared base name (_response) all resolve. ActualName is unchanged so the
  fields still reassemble into the single composite SQL argument.

Tests: ProxyHttpTypeProbeTest adds converted-name redirect, expanded-name
redirect, and oversized-field-skipped cases. Full suite green (2291).

See changelog/v3.18.2.md. version.txt / npm not bumped yet.

…oints

The TypeScript client generator was broken for any endpoint using
@body_parameter_name:

- It emitted "body: request.<name>?" — the TS optional "?" suffix (added for
  parameters with a default or a custom type) leaked into the runtime property
  name, a syntax error. The query-exclusion key was likewise ["<name>?"], so the
  body parameter was not stripped from the query string. Now the bare converted
  name is used for both the body expression and the exclusion key.

- It emitted a fetch body even for GET, which fetch forbids. A body is now only
  emitted for methods that can carry one (not GET); a GET body parameter (e.g. a
  server-filled HTTP Custom Type field forwarded by a proxy POST) is simply
  excluded from the query and not sent.

- It matched @body_parameter_name only against the converted and actual names,
  so the expanded HTTP-type field name (e.g. _response_body) was ignored — the
  parameter leaked into the query and no body was emitted, even though the server
  resolved it. The generator now also matches the ExpandedName alias, consistent
  with the server-side body-parameter resolution.

Tests: NpgsqlRestTests/TsClientTests/BodyParamGetTests.cs covers a GET endpoint
(converted name) and a POST HTTP-Custom-Type endpoint targeted by the expanded
name _response_body. Full suite green (2293).

See changelog/v3.18.2.md. version.txt / npm not bumped yet.

…arams from generated requests

New opt-in option (default false) on TsClientOptions, HttpFileOptions, and
OpenApiOptions. When enabled, parameters that are filled by the server and
cannot be set by the client are omitted from the generated request shape:
the TypeScript request interface, the .http query string / JSON body, and the
OpenAPI query parameters / request body.

A parameter is omitted when it is automatic AND optional. The shared rule lives
on the core endpoint as RoutineEndpoint.OmitParameterFromGeneratedRequest, built
on RoutineEndpoint.IsAutomaticParameter, so all three generators stay consistent:

- always automatic: HTTP Custom Type fields, resolved-parameter expressions,
  upload-metadata parameters;
- automatic only when the endpoint uses user parameters: IP-address and
  user-claim parameters;
- optional guard: HasDefault or a composite/HTTP-type field, so omission can
  never make a required argument un-sendable.

When every parameter is omitted the request collapses cleanly: a no-argument
TypeScript function, a bare .http URL, and no OpenAPI parameters/requestBody.

Default is false to keep generated output byte-stable on upgrade; each generator
opts in independently. The option is wired through the client config for all
three plugins (binding, ConfigDefaults, schema, template, appsettings.json).

Tests: omission coverage for each generator (TsClientTests/HttpFilesTests/
OpenApiTests OmitAutomaticParamsTests), reusing the tsclient_test.bodyparam_*
HTTP-type fixtures with separate omit-enabled generator configs. Full suite
green (2299).

See changelog/v3.18.2.md. version.txt / npm not bumped yet.

…; unify body-param matching

The HTTP file and OpenAPI generators matched the @body_parameter_name parameter
with a case-sensitive Ordinal comparison against only the converted and actual
names. An HTTP Custom Type field targeted by its expanded name (e.g.
_response_body) was therefore not recognized as the body parameter: it stayed on
the query string instead of being moved into the request body. (The TypeScript
client and the server were already fixed; these two generators had drifted.)

Body-parameter resolution is now a single shared rule, RoutineEndpoint.
IsBodyParameter(param) — case-insensitive, matching the converted, actual, or
expanded per-field name. Every call site routes through it: the proxy forwarder,
the request-handling body branch, and the TypeScript, HTTP file, and OpenAPI
generators. No more re-inlined three-name comparisons to drift.

Tests: HttpFilesTests/BodyParamToBodyTests and OpenApiTests/BodyParamToBodyTests
assert that an expanded-name body parameter is emitted as the request body (not
the query) in both generators. Full suite green (2301).

See changelog/v3.18.2.md. version.txt / npm not bumped yet.