Podziel OpenAPIDynamic.swift na małe pliki według odpowiedzialności

[mikolaj92]

Summary

Cały produkt siedzi w jednym pliku Sources/OpenAPIDynamic/OpenAPIDynamic.swift (~1034 linie): RequestBuilder, DecodingFailureContext, klient, błędy, decode(), HTTPResponse.validateSuccess, wszystkie overloade dekodowania, MiddlewareTransport.

Sąsiad OpenAPITransportKit ma osobne pliki/moduły na jedną robotę. Tu jeden god-file miesza builder, transport, błędy i Codable.

Why

Trudno recenzować i testować jedną ścieżkę. Duplikacja builder vs (method, url) w dekodowaniu jest skutkiem tego pliku.

Done means

• Osobne pliki w targecie OpenAPIDynamic, np. RequestBuilder, Errors, Client, MiddlewareTransport, Decoding
• Publiczne API i nazwa produktu bez zmian
• swift test i swift build w example-project przechodzą
• Brak nowych targetów SPM, chyba że naprawdę potrzeba osobnego produktu

Out of scope

Nowy FastAPI/Fala/app-factory. Zmiana semantyki requestów.

[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.