sendRequest<T: Decodable> dekoduje nil body jako Data() zamiast DecodingError.noData

[mikolaj92]

Summary

Trzy ścieżki dekodowania w Sources/OpenAPIDynamic/OpenAPIDynamic.swift mają trzy kontrakty na puste body.

• decode(_:from:) przy nil rzuca DecodingError.noData.
• sendRequest<T: Decodable> / sendRequestAndValidate<T: Decodable> robią decoder.decode(T.self, from: data ?? Data()) — nil staje się pustym Data() i wychodzi Swift.DecodingError.
• sendRequestWithResponseBody<T: Decodable> przez data.map zwraca (response, nil) i nie rzuca.

README obiecuje DecodingError.noData przy braku body.

Why

Caller nie może polegać na jednym błędzie. decodingFailureHandler dostaje inny error niż helper decode(). Testy jednostkowe tego nie łapią.

Done means

• Ścieżki sendRequest<T> i sendRequestAndValidate<T> przy data == nil rzucają DecodingError.noData
• sendRequestWithResponseBody<T> ma udokumentowany, testowany kontrakt na nil vs puste Data()
• Unit test z MockURLProtocol: nil body i zero-byte body, osobno
• decodingFailureHandler dostaje ten sam error co caller

Out of scope

Zmiana limitów maximumResponseBodyBytes. Live testy httpbin.

[mikolaj92]

Biorę ten spójny pakiet na mini-m4-1 razem z #9–#12. Pracuję z aktualnego origin/main; najpierw fail-closed API i deterministyczne testy, potem bezsemantyczny podział pliku, pełny Swift gate i PR.