fix(runtime): no-arg action commands fail to type-check in consumers

[Tam2]

Follow-up to #5. 0.1.9's generator emits a no-argument command for endpoints with no path params and no request body:

export const postBillingReactivateCommand = command(
  z.void(),
  async () => handlePostCommand('/billing/reactivate'),   // 1-argument call
);

But handlePostCommand(path, input) declared input as required, so the generated file itself failed to type-check in the consuming app:

error TS2554: Expected 2 arguments, but got 1.

(It worked at runtime — input was just undefined — so only type-check / CI was affected.)

Fix

Make input optional on handlePostCommand/handlePatchCommand/handlePutCommand. buildRequestOptions(undefined) already yields no params and no body, so behavior is unchanged. No regeneration needed to adopt — existing 0.1.9 output type-checks as soon as the handler is optional.

Verified

• Unit test: handlePostCommand('/x') (1 arg) → client.POST('/x', {}).
• Against a real consumer app: temporarily dropped in the built dist and re-ran svelte-check — the "Expected 2 arguments" errors went from N to 0.
• Build + 108 tests + typecheck all green.

Note

This slipped through because the library doesn't type-check its own generated output — only the generator's string output and the runtime handlers, separately. Worth a follow-up: compile a generated fixture in CI so consumer-facing type breaks are caught here. No version bump.

[Tam2]

Addressed the note in this PR (d75bfb2): added a generated-output type-check test that generates from an edge-cases fixture (covering every shape, incl. the no-path/no-body z.void() case that none of the real fixtures had) and compiles the output with tsc against the real createRemoteHandlers signatures + a $app/server stub. Verified it fails with the exact Expected 2 arguments error when the handler fix is reverted — so this class of consumer-facing type break is now caught in CI, not downstream.