When the hashed file is read in its entirety and has been transferred to sha256_update(), all that remains is to call the final sha256_final() function, which, if the file size was not a multiple of 64 bytes, adds extra padding bytes, inserts the total length of data in bits at the end of the last data block and makes the final sha256_transform().

The hash result stays in the state array.

This is a "high level" so to speak.

For the bitcoin miner, of course, the developers think how to calculate less but more effectively.

It's simple: the header contains only 80 bytes, which is not a multiple of 64 bytes. Thus it would be necessary to do two sha256_transform() for the first sha256. Luckily for the miners, however, the nonce of the block is at the end of the header, so the first sha256_transform() can only be done once - it will be a so-called midstate. Next, the miner goes through all the nonce options, of which there are 4 billion, 2^32, and substitutes them in the appropriate field for the second sha256_transform(). This transform completes the first sha256 function. Its result is eight 32-bit words, that is, 32 bytes. Finding sha256 from them is easy - the terminating sha256_transform() is called, and that's it. Notice that the 32-byte input is smaller than the 64 bytes needed for sha256_transform(). So again the block will be padded with zeros and the block length will be written at the end.

All in all there are three calls to sha256_transform() of which the first one needs to be read only once to calculate midstate.

I tried to expand all data manipulations occurring when bitcoin block header hash is calculated in one function, so that it would be clear how all the calculation is done specifically for bitcoin