I don't know if the bit gets reset in $420B after the transfer is over but it's pretty irrelevant, I think, since the register is write only. (I guess a read returns open bus data but I didn't look it up or anything). You will need to write to the register again to initiate additional transfers.

HDMA doesn't transfer data immediately. There's some wait and setup time during each hblank where HDMA has to figure out what it's doing, and that will depend upon how many channels are being used, and whether direct or indirect mode is being used for each channel. Indirect mode requires more time to get setup. Your assumption that DMA only activates during Vblank is not necessarily true, though due to a hardware bug in revision 1 of the SNES, there can be a conflict between HDMA and DMA if both are being used concurrently. Naturally the conflict would occur outside of Vblank because HDMA doesn't occur during Vblank. Thus, it's probably best unless you absolutely have to to keep your DMA transfers inside VBlank when also using HDMA. Most things that DMA is good for should be done during Vblank anyway (updating graphics, palettes and OAM, mainly). The point is that a DMA transfer begins as soon as you write to $420B, whereas HDMA should be configured to activate ahead of time (do it during Vblank when HDMA isn't running) and consists of one or more short transfers occuring each HBlank.

During each Vblank, you have to reenable HDMA ($420C) for the channels you want to be active on the next frame. This is because HDMA is deactivated for all channels at the start of Vblank (think of it as $420C being set to 0x00).

Also, it's very possible to go past the end of Vblank with several large DMA transfers or time consuming code within an NMI routine. It's not like the system automatically makes everything all better when it comes out of Vblank, so keep that in mind. You only have so much time during Vblank, you have to make efficient use of that time.

Yes.  What's basically happening is that the CPU is busy performing the DMA so it doesn't have time to execute instructions.  Since the PPU operates independently of the CPU and DMA, it continues to move forward during this time.  As does everything else on the system.

Okay, so HDMA only transfers on H-Blank, so does it only freeze the CPU on H-Blank?  Can other instructions be executed not during H-Blank?  And if so can those instructions executed affect the HDMA by changing the registers?

Is there any easy way to tell how many instructions/cycles will be executed between each H-Blank?

I was meaning not during H-Blank but in between them.  So if i schedule an HDMA how many instructions/cycles can I expect to execute per scanline before the H-Blank, so I know how much time I have to manipulate the HDMA registers, or whatever else I want to do.

It depends on how much data you are transferring. HDMA doesn't consume 100% of Hblank. It can be very short, needing only ~40 cycles, or very long, needing ~400 cycles. However much it consumes sans 1324 is how much time you have before the next HDMA transfer.

Also, DRAM refresh occurs at H=530-538. It varies based on the CPU revision. But it only happens once per scanline.