test: restore coverage lost in #537

[razor-x]

Follow-up to #537. After it merged, I audited every deleted spec assertion against what remains on main and found two places where real SDK behavior lost its only coverage. This restores both — specs only, no SDK changes.

What the audit found

1. Malformed error response handling (spec/seam_client/malformed_response_spec.rb)

#537 deleted spec/seam_client/request_spec.rb claiming its coverage was folded into http_error_spec against the fake. That was only partly true. The fake's simulated outage responds with a bare 503 — no content type, empty body — so of the branches in seam_api_error_response? only the content-type guard stayed covered. Three fall-through paths lost their specs:

• malformed JSON with a JSON content type (rescue JSON::ParserError)
• a JSON body without an error object
• an error object without string type and message fields

Restored with WebMock, which is the right tool here for the same reason it backs the headers and retry specs: the fake cannot produce these responses.

2. Resource error and warning coercion (spec/resources/resource_errors_spec.rb)

#537 deleted the per-route client specs as generated-code tests, but three of them (devices_spec, access_codes_spec, connected_accounts_spec) were the only coverage of ResourceErrorsSupport and ResourceWarningsSupport — the modules that convert error/warning hashes into ResourceError / ResourceWarning objects with parsed created_at dates. Codegen marks these as hand-maintained (“durable”) static files, so they are SDK behavior, not generated code. After #537: zero assertions on .errors.first.error_code anywhere in the suite.

Restored at the resource level where the behavior lives, including the [] default when a resource carries no errors or warnings, plus a small DeepHashAccessor example for hashes inside arrays, which those specs exercised indirectly.

One correction to the #537 description

#537 said the deleted action-attempt resource spec “stubbed :get on /action_attempts/get while the SDK POSTs to it.” That was wrong: Helpers::ActionAttempt.update_action_attempt does use client.get, so the old stub was consistent with the helper. No coverage was lost there — the wait specs exercise the same path against the fake — but the stated justification was incorrect.

Verification

86 examples, 0 failures

Up from 77 on main: +4 malformed response, +4 resource errors/warnings, +1 accessor. rake lint is clean.

The Python SDK never had the malformed-response coverage either; seamapi/python#599 adds it there for parity.