Out-of-bounds read in reloc_names when input ELF has relocation types beyond the o32 basics (crash on Windows)

Problem

reloc_names in src/main.cpp has 8 entries, covering only the basic o32 relocation types (R_MIPS_NONE through R_MIPS_GPREL16). But Reloc::type is filled directly from the raw ELF r_type field with no range check (elf.cpp: static_cast<RelocType>(rel_type)). An ELF containing relocatable/PIC code can carry higher-numbered relocation types -- R_MIPS_GOT16 (9), R_MIPS_CALL16 (11), R_MIPS_GPREL32 (12), and so on -- so reloc_names[reloc.type] reads past the end of the vector.

Symptom

The out-of-bounds std::vector::operator[] is undefined behavior. On many libstdc++ builds it happens to be harmless, but with the MSVC STL the returned reference is garbage: it looks like a std::string with an enormous length, so fmt throws std::bad_alloc while writing the overlay relocation table. The recompiler aborts partway through and leaves truncated output files.

Reproduction

Statically recompile a game whose overlays were built as PIC, so its relocation sections contain GOT16/CALL16 entries. On Windows the recompiler crashes mid-output.

Suggested fix

Bounds-check the lookup at both call sites (dump_context and the overlay reloc table writer). Since these relocation types are not supported by the recompiler anyway, an explicit error naming the offending type is probably better than printing a placeholder -- silently emitting R_MIPS_NONE would make the runtime skip relocations that the input actually needs.