diomedea

Your output_log from the most recent crash shows you are running KSP modded (specifically, Kerbal Engineer and MechJeb2). Delete those add-ons and test if the issue persists. You may have installed an obsolete version of those, or have incurred in an issue with one add-on, to be reported with that add-on thread (or, if you can't identify a specific add-on causing the issue with a modded install, report here). Only in case you verified the issue with a pure stock KSP install, provide us all the info suggested here.

For what I know, the operating system may force a low but safe screen resolution when the one required by an application isn't supported (something alike a control panel should list all supported resolutions with your display).
KSP stores the resolution in the settings.cfg (lines "SCREEN_RESOLUTION_WIDTH = " and "SCREEN_RESOLUTION_HEIGHT = "). Of course those can be changed via the settings (Graphics) in game, but better check what really is stored. It should also work directly editing those two lines with values supported by your display.
Therefore, check what the values stored are; if they don't both match one of the supported resolutions, change them to one supported you like. Maybe do some experiments with lower resolution first, I've heard of some crazy high resolution being working in KSP but can't tell if the one you wish would. Also, did you change any other graphical settings before having this issue? Not having a Mac can't tell, but could be possible not all combinations of settings like V-sync or Frame Limit work at such resolution (Frame Limit in particular, its frequency by Width by Height by 4 defines the number of bytes your GFX must send to the display each second, with a Frame Limit = 120 that would amount to ~7.1 GB/s which is pretty high and may not be supported).

Can confirm this shows in stock game (for reference: KSP 1.2.2, build 1622, at least with standard graphical settings).
However the effect could be considered correct because of how KSP works. With the light source (Sun) so low to be tangent to the horizon, all vertical surfaces exposed to the source are getting the maximum possible density of light power (Watt/m2). In KSP, at the average distance of Kerbin from Sun, solar irradiance is identical to Earth's = 1361 W/m2) and is normally considered for its thermal effects on ground (being the ground generally horizontal, the maximum effect is when the Sun is at the local zenith, 90° elevation). On every surface, power density goes with the sine of the angle between Sun direction and that surface plane. Therefore, horizontal surfaces are all receiving Pmax *sin(elevation) power, but vertical surfaces receive Pmax*sin(90°-elevation), and the power on them is highest when Sun is directly in front of those surfaces (which happens at Sunrise for walls exposed to East, and Sunset for those exposed West). The effect is starker due to the low illumination of horizontal surfaces at the same time, due to the very low incidence angle of Sun at Sunrise/Sunset on ground.
Now, as certainly the many who know about shaders in KSP will notice, a realistic effect should also consider the factor of absorption of light while traveling within an atmosphere (of course goes with the density and length of atmosphere travelled), which would produce a lower Pmax on ground: being the length of atmosphere travelled the longer at Sunrise/Sunset, Pmax should be lower, making those shines less evident. Another effect would be the change in wavelength due to Kerbin's rotation: at Sunrise, the rotation goes "towards" the light source, so the wavelength is shorter (and visible light turns blueish); at Sunset the rotation goes "away" from the light source, the wavelength is longer and visible light is more reddish. Unfortunately stock KSP has none of these effects due to atmosphere absorption and body rotation on visible light.

Can confirm, it's a hyperbolic escape trajectory. The current orbit (Ap = 1085 Km; Pe = 230 Km above Minmus surface) should have velocity = 98.574 m/s at periapsis. The required orbit (Ap = -399 Km) has velocity = 290.261 m/s at periapsis, so you have to burn prograde at periapsis for DV = 191.687 m/s (beyond the slight normal change to meet inclination, LAN and LPE).

Pls show your ship, it may have RCS thrusters misplaced. Firing 4 instead of 2 is normal when thrusters are in a X cross configuration (pic below should make this clear), but thrust of those 4 sums to give the same as 2 in a right cross. However, you may also have center of thrust from RCS misaligned with the vessel CoM, so each time you want to translate, you also thrust to make a rotation (and then, having both SAS and RCS on, thrusters are fired to cancel the unwanted rotation, so you're actually seeing that retroaction). If that's the case, you may find RCSBA useful to check thrusters position while building vessels.

(Also, this fits in GamePlay Questions, rather than Technical Support, at least until confirmed you are having a bug. Moved for now)

I've now tried your vessel, and it flies fine without any modification (). Had no problem controlling the ascent. Can see from your "ascent profile GIF" there seems to be no active control while the vessel is in flight (roll/yaw/pitch indicators stay neutral) but can't see why, seems like nobody is at the helm. You may see I use SAS (though not strictly required, but helps) and just a tiny bit of control, to keep the vessel aimed correctly.

Not owning a device alike your USB audio interface, checking what causes the issue and giving correct advice is close to impossible. So, take what I'm writing with caution.
Your audio interface is indeed a sophisticated device, to perform better it uses software alike all modern digital musical instruments (a DAW, e.g. Ableton). That means the audio files are processed through the DAW, of course that is resident in memory. The DAW requires the audio file to be sent to it at the same time it would be played (through DirectX) from your PC native audio interface (then, to your headset that I understand is directly connected to the PC, instead of through the Focusrite).
During initial loading, KSP (as well as any software) loads a wealth of data from disk (the OS takes care to load all needed from disk to memory and reserves that memory to KSP). Memory isn't only RAM, it includes the swap file that is written to disk. When RAM isn't enough to hold all, those pages in memory that weren't accessed recently are swapped to disk. Of course, having multiple programs open at the same, means they all "fight" for available RAM. Given your system has 8 GB RAM, and KSP 1.2 unmodded alone loads in 1.8 GB, is quite possible your OS is finding a shortage of RAM and then needs to swap memory. Just when the DAW should be playing those audio files, is quite possible those files (and possibly even some of the DAW software itself) have to be swapped back to RAM to be accessible. In fewer words, it all is due to the bottleneck of the system in passing data from disk to RAM.
Clearly, there is no error to be reported about the time taken to move data, no wonder you'll find none with system and KSP logs; but you may find some programs able to show how memory is used and the amount of data moved by your system in real time, those would help diagnose the issue.
Can't really tell about the VAB, sure if the vessel you were building was complex, would require more RAM, and that alone would push other things to the swap file. Quite possible the audio parts among them. But you told it takes few parts to have that effect, so something else could be the cause.
Of course, more RAM could solve the issue if swapping memory is really the cause; a SSD to host the swap file would also help greatly. But I'd not commit to buy components before having confirmed that is really the issue.