Known error responses

Curiously, the OpenAPI REST specification documents that the server may return HTTP status code 400 in some situations, but not in others that seemingly would have a higher propensity for error.

eg;
- `/v2/` (the parameterless server metadata endpoint) may respond with HTTP status code 400, while `/v2/models/{MODEL_NAME}/versions/${MODEL_VERSION}` (the parametrized model metadata endpoint) is documented to only respond with HTTP status code 200,
- liveness and readiness only return status code 200 meaning their differences to kubernetes are non-existant.
- Details on why liveness and readiness as documented are identicalIf the only documented HTTP response codes are 200 for liveness and readiness, then implementors can only assume that a spec-compliant server never responds with anything other than 200, meaning, if the server is reachable (a TCP connection can be established), then there is no difference between liveness or readiness since both APIs return the same code.

Relatedly, the gRPC spec does not mention possible error codes at all. Protobuf doesn't really have a mechanism in the language to document rcp error codes aside from comments, but a bit of documentation there about what clients can expect would be good as well.

Start with the OpenAPI definitions for /v2/, /v2/models/{MODEL_NAME}/versions/${MODEL_VERSION}, liveness, and readiness, then review the gRPC service specification. Compare their documented success and error responses, including the Kubernetes liveness/readiness distinction, and document the agreed codes; done when both protocol specifications consistently state expected responses.

Written by the indexing model from the issue text.