[Coastrnaut]

Shader::CompileProgram() compiles the vertex shader, then the fragment shader. If the fragment shader fails to compile, CompileShader() throws and the already compiled vertex shader object is never deleted. This happens every time a preset whose (transpiled) shader doesn't compile is loaded, so apps that keep switching presets slowly accumulate shader objects and the driver memory behind them.

This change deletes the vertex shader before rethrowing. The successful path and the thrown exception are unchanged.

Related to #1000. This removes one source of growth there, but not all of it: in my tests the rest of the growth is held by the GL driver (NVIDIA) and grows mainly the first time each new preset is used.

Measurements

Windows, RTX A6000, GL 3.3 core, presets switched with projectm_playlist_play_next() while the preset is locked (the setup from #1000):

	master	this PR
200 switches, alternating a preset with a failing shader and a working one: leaked shader objects	100	0
... heap growth	16.8 MB	2.6 MB
1,500 soft-cut switches through cream-of-the-crop: leaked shader objects	3	0
... private memory growth	199.9 MB	144.6 MB
... heap growth	61.5 MB	47.3 MB

Backwards compatibility

I loaded all 14,536 presets from cream-of-the-crop, en-d, milkdrop-original and projectm-classic one after another, rendering 30 frames each with fixed audio and frame times, and logged every glCompileShader/glLinkProgram result, failed preset loads, live shader objects and frame hashes. For the pixel comparison both builds had their random seeds fixed (a local patch only, identical on both sides).

• Shader compile results, link results and failed loads: identical for all presets.
• Rendered frames: identical for all 14,535 presets that render deterministically. One preset doesn't render the same way twice even on master; its frames from this PR match one of the master runs.
• The 65 presets whose fragment shader fails to compile render the same fallback as before.
• Leaked shader objects at the end: master 65, this PR 0.

Unit tests pass. There's no new unit test because the test suite doesn't create a GL context.

#1026 contained the same change as part of a larger, closed PR.

Retested on current master (2026-11-12)

• Unit tests: 164/164 libprojectM and 98/98 playlist tests pass.
• Presets: I loaded all 14,536 presets from cream-of-the-crop, en-d, milkdrop-original and projectm-classic one after another with this branch and with master (GL 3.3 core, RTX A6000, preset folders as texture search path, 30 frames each with fixed audio, frame times and random seeds; the seeds are a local patch only, identical on both sides). Shader compile/link results and failed loads are identical to master, and no shader objects are left over. Rendered frames are identical except for $$$ Royal - Mashup (257), which also renders differently between two runs of master.
• Together with my other PRs: All my open PRs (Fix calling convention of glGetStringi pointer in GLProbe #1059 to Build for Windows Store (UWP) without app-side workarounds #1065, Return int from the NaN-safe multiplication of two ints #1067 to Fix shaders that declare or name samplers through macros #1072, Build Apple frameworks for iOS, tvOS, watchOS and visionOS, and support EAGL contexts #1075, Don't shift the blur textures by Direct3D's half-pixel offset #1078 and Render with 10 bits per color channel if the target framebuffer has more than 8 #1079) merge with each other and with master without conflicts. Merged together (all except Render with 10 bits per color channel if the target framebuffer has more than 8 #1079, which I opened after this run), they build on desktop GL and GLES, all unit tests pass, and the corpus gives 0 failed loads, 0 shader compile/link failures and 0 GL errors in an OpenGL ES context, with and without textures.