On a bare-metal target, what plays the role of the "loader"?

Two things together, because there's no operating system to load the program. First, a flasher/programmer (driven over JTAG or SWD, or via a built-in ROM bootloader) writes the firmware image into the chip's non-volatile flash, this happens once at programming time. Second, the on-chip startup code, the reset handler, acts as the runtime "loader" at every power-on or reset: it copies the initialized data section (.data) from flash into RAM, zeroes the .bss section, sets up the stack pointer and (on Cortex-M) the vector table, optionally configures clocks, runs C++ static constructors, and then jumps to main. So on a desktop the OS loader does mapping, relocation, and dynamic linking each time you run the program, whereas on embedded the equivalent work is divided between a one-time flash step and the startup code that re-initializes RAM on every reset. This matters because a program can link perfectly yet still not run if the startup code or linker script is wrong, the "loading" responsibilities you take for granted on a hosted system are now your code's job.