fix(sdk): give the retryable status a type of its own

Every one of the five SDKs classified 401, 403, 404, 409, 429 and 501 into a
dedicated error class and let 503 fall through to the base one. Go typed 400 as
well and still not 503.

That inverts the mapping against usefulness. 501 Not Implemented is permanent —
the active engine cannot do this and never will, so retrying is pointless — and
it had a type everywhere. 503 is the transport failure a caller should retry,
and it had none: a caller wanting to retry had to reach past the typed surface
and read the raw status off the base error.

The timing is what makes it matter now. 0.14.5 turned 503 into the standard
answer for "WhatsApp never confirmed the operation" across the engine surface,
and 47 of the 189 published operations document one. These error classes were
designed when the status barely occurred.

Each SDK gains one class or sentinel and one branch. The doc comment says it is
retryable, and notes that the gateway deliberately leaves the non-idempotent
sends — group create, channel create, media send — unbounded precisely so they
never answer a 503 for a caller to retry into a duplicate.

Tests cover the classification in JavaScript, Python, Java and Go. The Go case
also asserts a 503 does NOT match ErrNotImplemented, since a sentinel that
matched both would tell a caller to give up on the retryable one.