czy kompilator może dołączyć nagłówki lub funkcje w sposób ukryty?

Ok. Ale wciąż nie wiadomo, dlaczego mi błędów nie pokazuje

jutro sobie jeszcze przestudiuje cmake i strukturę katalogów Twojego projektu, może w nim czegoś nie dołączyłem, więc się tym nie przejmuj. Skuszę się i zainstaluje VS2022 i zobaczę czy projekt "Open-Dialog-Box" kompiluje się bez cmath.

//edit
zainstalowałem VS2022 i faktycznie nie sygnalizuje ostrzeżeń ani error'ów
Open-Dialog-Box pomimo braku dołączonej biblioteki <cmath> skompilował się .
Stworzyłem nowy projekt w czystym C++ (konsoli cmd), skorzystałem z funkcji Sqrt(), Pow() bez dołączania cmath i MSVC kompiluje bez ostrzeżenia związanego z brakującym nagłówkiem
Jeżeli chodzi o nie zgłaszanie błędów przy próbie konwersji z std::wstring do std::ofstream, myślę że zachodzi tutaj do niejawnego (automatycznego) rzutowania typów. Pewnie przy odpowiednich ustawieniach poziomu ostrzeżeń lub włączeniu odpowiednich flag, kompilator wychwyciłby takie problemy.

GCC jest kompilatorem, który bardziej rygorystycznie przestrzega standardów C++ i dlatego dostaje ostrzeżenia i komunikaty o błędach.
Twoje projekty są napisany w VS więc tak widocznie może/musi być.

To kwestia niestandardowych rozszerzeń MSVC, jak poczytamy w dokumentacji https://learn.microsoft.com/en-us/cpp/standard-library/basic-fstream-class?view=msvc-170#basic_fstream
Istnieje taki konstruktor, rzekomo. I w analogii do zmian API w C++11, pewnie wersja wstring też, dlatego kod tBane się kompiluje. W dokumentacji opartej o standard C++ nie ma takiego wariantu
https://en.cppreference.com/w/cpp/io/basic_ofstream/basic_ofstream
Wariant trzeci jest odpowiednikiem tego konstruktora z dokumentacji MSVC:
Ale bez dodatkowego domyślnego argumentu i to jest tylko wersja wskaźnikowa jako alternatywa nie dla (w)string, ale dla std::filesystem::path. Żeby być przenośnym, najlepiej użyć właśnie std::filesystem::path.

Błędy znaczą że program jest błędny. Natomiast między wersjami kompilatorów są różnice w niestandardowych rozszerzeniach oraz wzajemnym dołączaniu się standardowych nagłówków, co maskuje błędy i po zmianie kompilatora kod może się przestać kompilować. Do tego różne wersje standardu C++, makra preprocesora definiowane przez opcje kompilacji, etc.. Jest trochę rzeczy które nie występują w samym kodzie a mają znaczenie dla kompilacji, więc taka zmiana kompilatora i sposobu budowania może nie być taka prosta.
Natomiast ostrzeżenia to wyłącznie miły gest od twórców kompilatora i dlatego należy ostrzeżenia czytać. Kompilator nie ma obowiązku ostrzegania o niczym.

Nie zdawałem sobie sprawy, że pomiędzy wersjami kompilatorów (GCC vs. MSVC) mogą występować istotne różnice w zakresie niestandardowych rozszerzeń oraz w mechanizmie wzajemnego dołączania standardowych nagłówków. Sądziłem, że jeżeli kompilator obsługuje dany standard, to jego podejście do implementacji będzie jednolite i spójne, co było moim błędnym założeniem, wynikającym z używania na co dzień kompilatorów g++ i clang.
@pekfos dzięki za za poświęcony czas i wyczerpujące wyjaśnienia, raczej nie będę dostosowywać kodu do bardziej ogólnych funkcji, które będą kompatybilne z każdym kompilatorem

Standard mówi co jest zdefiniowane w jakim nagłówku, ale #include to dosłownie automatyczne kopiuj-wklej, wiec dołączają się rzeczy które nagłówek sam dołącza, z jakiegokolwiek powodu. Pisząc kod opierając się o feedback błędów kompilatora, możesz nie dać wszystkich wymaganych nagłówków wg standardu i kod może się kompilować tylko dzięki szczegółom implementacji tej konkretnej biblioteki standardowej. Jak zmienisz kompilator i bardzo możliwe że też implementację biblioteki standardowej, to się zrobi problem. To jest wada tego systemu.