How to program the part, what is available is all documented in the ST documentation, between the datasheet and the reference manual.
The boot0 pin (datasheet usually) as shown in the documentation (reference manual usually) shows what the boot paths are when reset or powered on with the boot pin in that state. Other than the latest wave of products from them that meant it boots from your code (application flash) or from the bootloader. You can do an sram thing too but dont worry about that all you need to do is read the docs and this is clear.
That part has a bootloader that can be programmed using uart or probably i2c maybe spi (but NOT usb).
When designing a product around one of these microcontrollers you have to decide how you want to program it. pre-program it and provide no field programmability, use pads/jumpers/headers to use one of the programming methods provided by the part, or make a bootloader where you choose the path (none of the above as you are in your bootloader not theirs so you create the protocol, etc).
There are also the swdio and swclk pins (datasheet) that provide access to the arm core, the arm core then can be halted and through that swd interface (jtag like, but not jtag) you can access the arm bus and if/since the arm bus can talk to the st logic and program the flash then through that path you can program the flash if you have the right software. openocd happens to know how to handle that part (flash programming these days is part specific not generic so requires code for each one or you download your code to ram and then that code programs the flash).
So when you hook up an stlink or jlink or other debugger to the bottom end of that board you are coming in through that swd interface. So long as you have not hung the arm core, you can go through it to get at the flash, ram, peripherals, etc. If you have hung it you have the boot0 pin you can use to boot into the debugged bootloader from which you can then halt that through the debugger and then program the application flash or load a program in ram or whatever.
stlink, jlink, are just interface boards, they need software that can speak their langauge to then ask them to perform the swd protocol commands for you. openocd and others also support ftdi parts with mpsse which is a tiny state machine language if you will to tell the part to wiggle pins for you in a timed manner. ft2232, ft4232 and a number of others but not all. FTDI is well known for usb to something parts, and the 2232 and parts like it support uart out of the gate but also have big bang modes and mpsse mode and in that mode you can do i2c, spi, jtag, swd, and whatever other protocol you wish within the pins available. So a simple ftdi breakout board will work just fine for doing swd. Get one with two or more ports exposed and you can do both swd and uart and not need two boards.
When you buy a nucleo board it has another mcu on it a debugger, which also supports the stlink protocol which is a usb protocol from st, but it is just an interface, openocd can be used with stlink to program nxp or atmel or other parts with cortex-m cores in it not just ones from st, but the onboard debugger is wired to the target mcu such that it can reprogram that mcu. That debugger end also on some of the boards provides a virtual com port connected to the target uart, so that you can through usb get uart/serial access to the target mcu without having to buy extra hardware. Also that debugger creates a virtual thumb drive, you drag and drop your .bin file (arm-whatever-objdump -O binary hello.elf hello.bin) and the debugger mcu will take that file and program it into the target mcu's flash and reset the target mcu.
The blue pill though was very popular and still is for the arduino world trying to get a non-avr with some horsepower. A fair amount of work was put into that including a usb based bootloader that speaks a protocol that arduino (the tools) supports (meaning someone created a protocol and added arduino support and a bootloader). If either through that protocol or through one of the other entry points you overwrite that bootloader (trivial to do) then you use that usb programming capability and have to use one of the other paths to put that bootloader back on. So this is a case of a roll your own bootloader that didnt come from ST. Because the blue pill has been so massively cloned there is no reason to assume that any one you buy will come preprogrammed with it.
For about $5 you can get a not really a jlink board, little purple thing, look for stm32 jlink even though it has no affiliation with either (well it may speak the jlink usb protocol sure). For about $10 you get into the nucleo cards which the wider ones the debugger end is physically removable but you dont have to do that remove two jumpers and use four wires and you can use that front end with openocd or whatever to program most anything cortex-m based. Many if not all of the (real) discovery boards can do that too. If you are tired of getting ripped off on ebay you can sometimes find the $5 jlink board on amazon or other for a bit more. You can also find an ftdi breakout board on adafruit, I am looking at one right now ft232h. note that not all ft232 parts will work, you have to confirm it by doing a little research. The adafruit board is single ported and/or only has one port exposed so either swd or uart but not both at the same time. For under $10 you can get a raspberry pi usb serial cable with four dangling female headers on the other end (has an ftdi part in it) and you can use it along with boot0 and some software (protocol is simple can bang out your own tool in one sitting) to use the uart interface (can do this with the ftdi board as well).
The newer stm32 parts (stm32g030 for example). If the application flash is erased then it will run the bootloader that supports uart, otherwise by default that is considered a security risk and wont. You can use that one shot to load a program that clears the security bits (non-volatile) and you can then use boot0 and the uart programming interface to your hearts content, otherwise swd is your path in, and thats it. Some part vendors swd is the only path. atmel (now microchip) used to have this sam-ba bootloader much like sts just different uart protocol (also pretty simple) but it is no longer embedded, they will give you source to it and you can put it on the flash yourself, but why bother it is way more bloated than something you could do yourself and their flash locking leaves a lot to be desired. I suspect st is going to go that way and not have the bootloader after a while. Some cortex-m vendors are swd only, that is all you get (and if you hang the arm you may have to remove the part and put another one down, so be careful)
Anyway 100% of this is documented, some in sts docs some in the blue pill main or fan pages, arms documentation, etc. But primarily the boot0/1 pins are documented by st as to what they do. There is documentation for the uart interface, note that over time the bootloader changed and not every part uses the same features, some require a page of this size or require (only support) the enhanced write over the regular write, etc. But the protocol itself will tell you what commands it supports. Again first time at it its an afternoon to write your own (may take you just as long to try to get someone elses tool to work) software to talk to the bootloader and program the flash. Some blue pills arrived locked and I had to use the uart bootloader to unlock. Later I think I figured out how to unlock them using openocd/swd. Once unlocked then it is unlocked and wasnt going to buy dozens of these to prove the theories.
