Independent validation ✅

Checked out this branch and ran it against a live Dokploy server (v0.29.x) with a real API key.

On main, every parameterized GET query fails with Request failed with status code 400. With this branch the same commands succeed:

• application one --applicationId <id>: 400 → 200, returns the full application payload.
• No-argument queries (e.g. project all) keep working — no regression.

The REST migration is the correct root-cause fix: current Dokploy servers expose these procedures under /api, not /trpc. This also resolves #46 (same underlying cause as #39) — the { json: ... } superjson-wrapping workaround suggested there is unnecessary once requests go through the REST endpoints.

The client.test.ts REST regression tests added here pass locally. Would be great to see this merged. 🙏

Independent verification against a live Dokploy v0.29.13 panel using @dokploy/cli 0.29.4 from npm (ids redacted):

project all      -> 200  (the only command that takes no params)
project one      -> 400
application one  -> 400
deployment all   -> 400
environment one  -> 400

So the breakage is every parameterized read, not just project one.

Raw requests isolate the cause — same procedure, three shapes:

GET /api/trpc/application.one?input={"applicationId":"<id>"}          -> 400   <- current apiGet
GET /api/trpc/application.one?input={"json":{"applicationId":"<id>"}} -> 200
GET /api/application.one?applicationId=<id>                           -> 200   <- this PR

Two details that support this PR's direction:

1. apiPost was never broken only because it already wraps payloads as { json: data }. That asymmetry with apiGet is the entire bug (also filed as GET (query) requests don't wrap input in {json: ...}, breaking every parameterized read against tRPC servers using the superjson transformer #46) — worth saying explicitly in the changelog, since from the outside it reads as "the server dropped tRPC support", which is not what happened.

2. The response envelope really does differ, and this PR handles it correctly:

GET /api/application.one       -> bare object: {appName, applicationId, applicationStatus, ...}
GET /api/trpc/application.one  -> {"result":{"data":{...}}}

So dropping response.data?.result?.data?.json ?? response.data is right for the REST route — whereas a minimal {json:…} fix on the tRPC route would have to keep it.

Scope caveat on my end: I verified the GET side live. I did not exercise the POST side against a real server (that panel is production), so client.post(/${endpoint}, data) is confirmed only against the documented REST contract (POST /api/application.deploy with {applicationId}), not by me calling it.