Distinguish failure classes in the exit status (auth, not found, network)

[sethfitz]

Problem

Every failure exits 1, so a script or agent can't tell why a command failed without parsing stderr. On 2.6.0:

command	good key	bad key (401)	endpoint unreachable
linear api '{ viewer { name } }'	0	1	1
linear issue view TARN-1	0	1	1
linear issue view TARN-99999 (no such issue)	1	1	1
linear api '{ nope }' (invalid query)	1

(unreachable = LINEAR_GRAPHQL_ENDPOINT=http://127.0.0.1:9/graphql)

This hurts most in unattended use. A revoked key looks the same as a missing issue, so a job that reads non-zero as "not found" keeps running and quietly does nothing once the key goes bad.

The types are already there. handleError in src/utils/errors.ts gets an AuthError, NotFoundError or ValidationError and calls Deno.exit(1) for every one. src/commands/api.ts exits 1 on HTTP >= 400 and on a non-empty errors array.

Proposed change

Give each error class its own exit code and document the codes in --help and the README. For example: 1 general, 2 usage (already what cliffy returns), 3 auth (HTTP 401/403, AuthError), 4 not found, 5 network. For linear api, a response with GraphQL errors could stay at 1, whether Linear sent it as HTTP 200 (execution error) or 400 (validation error), with 401/403 still going to 3.

Alternatives considered

Parsing stderr works, but error message text isn't a contract. JSON on stderr for --json commands would also work, but it's more to build than exit codes.