fix: guard StreamAPIException against empty / non-integer error bodies

[Loschcode]

Ticket

• https://linear.app/stream/issue/CHA-3655

Problem

StreamAPIException#error_code (Integer) and #error_message (String) are typed as non-nilable, but the constructor only assigned them on the JSON happy path:

begin
  parsed_response = JSON.parse(response.body)
  @json_response = T.let(true, T::Boolean)
  @error_code = T.let(parsed_response.fetch('code', 'unknown'), Integer)
  @error_message = T.let(parsed_response.fetch('message', 'unknown'), String)
rescue JSON::ParserError
  @json_response = false   # @error_code / @error_message left unset (nil)
end

Two real failure modes hit this:

1. Empty / non-JSON body (this ticket). When the API is fronted by a load balancer that emits a bare 503 with an empty body, JSON.parse("") raises JSON::ParserError. The rescue sets @json_response = false but never assigns @error_code/@error_message, so they stay nil. The exception constructs fine, but the moment a caller reads e.error_code (e.g. for logging) the Sorbet sig { returns(Integer) } on the attr_reader runtime-checks the value, sees nil, and raises TypeError: Expected type Integer, got NilClass (errors.rb:9) — masking the real HTTP error.

   Reported by Homebase on stream-chat-ruby 3.9.0:

   TypeError: Return value: Expected type Integer, got type NilClass
     at StreamChat::StreamAPIException#error_code (errors.rb:9)
   Caused by: StreamChat::StreamAPIException: StreamChat error HTTP code: 503
   Caused by: JSON::ParserError: An empty string is not a valid JSON string
   

2. Non-integer code. An edge rate-limit envelope returning code: "rate_limit_exceeded" made T.let(..., Integer) raise a TypeError inside initialize, so callers couldn't even rescue it as a StreamAPIException (previously reported, ticket #80594).

Fix

Seed both readers with sentinels (-1 / 'unknown') before parsing, and only overwrite them when the parsed body is a Hash carrying values of the expected type:

• error_code is always an Integer — never nil, never a crash on read.
• message() still falls back to the HTTP status when there is no usable JSON body.
• A missing, non-integer, or non-Hash body no longer raises.

This fixes both failure modes at the source rather than relying on the backend to keep emitting a shape the SDK happens to tolerate.

Tests

New network-free spec/errors_spec.rb covering: well-formed JSON, empty 503 body, non-JSON body, non-integer code, and a JSON body missing code/message.

6 examples, 0 failures        # bundle exec rspec spec/errors_spec.rb
2 files inspected, no offenses # bundle exec rubocop
No errors! Great job.          # bundle exec srb tc

Note for reviewers

lib/stream-chat/errors.rb is hand-written (no codegen marker). If the intent is for SDK error types to be self-generated, the same guard should be applied in the generator template instead — flagging for that discussion.

Checklist

• Unit tests added
• RuboCop + Sorbet pass
• CHANGELOG handled by standard-version on release (conventional fix: commit)