services add rejects --port 0, the worker shape the plane and deploy both support

[tonychang04]

What

insta services add compute <name> --port 0 is rejected by client-side validation:

$ insta services add compute wk --port 0
error: port must be an integer between 1 and 65535, got: 0

But port: 0 is a first-class service shape, not an invalid port. It is the worker shape: a long-running process with no HTTP endpoint (agents, queue consumers). insta-compute's README defines it explicitly — "port: 0 = worker: 没有 HTTP 端点的长驻进程 … 无 PORT env、无 ClusterIP" — and the plane, the platform API and insta deploy all support it.

The inconsistency

The deploy path accepts exactly what services add rejects, and behaves correctly:

$ insta services add compute wk            # default port, accepted
$ insta deploy --image alpine:3.20 --port 0 --group wk --json
{ "machineId": "insta-compute", "url": "", ... }     # empty url = no HTTP endpoint. Correct.

$ insta compute exec wk -- echo worker-alive
worker-alive

So workers are reachable today only by creating the service at some other port and then converging it to 0 on the first deploy. The one command whose job is "create a service of this shape" is the one that cannot express it.

Verified on prod, 2026-08-31, CLI 0.0.52.

Suggested fix

Allow 0 in services add --port's validator and document it as the worker shape (--port 0 = no HTTP endpoint), matching insta deploy --port. The range check should read "0, or 1-65535", with 0 named rather than silently permitted — the error message is otherwise correct and useful for genuine typos.

Worth checking in the same pass whether --port 0 at create needs to imply endpoint.mode=none, since the platform already converges port: 0 → none on deploy.