You seem to be working with the following:
01000000 00010100 00000000 00000000
00000000 00000000 00000000 00000000
00000000 000000ff ffffff31 03816b07
244d696e 65642062 7920416e 74506f6f
6c6b2f45 42312f41 44362f4e 59412f33
2059c36d 7be15500 00df3200 00ffffff
ff023825 2e4d0000 00001976 a9146603
71326d3a 2e064c27 8b20107a 65dad847
e8a988ac 00000000 00000000 266a24aa
21a9edc1 1e8cdbd8 d442b27b f8f27339
5baa83b5 da4c9c3d 87fbc539 dad74248
04371001 20000000 00000000 00000000
00000000 00000000 00000000 00000000
00000000 00000000 00
Notice the extra "0120" at the end followed by an extra 36 bytes of "00"?
Also notice that you have an extra byte of "00" between the 4-byte version (the 01000000) at the beginning, and the "01" representing the number of inputs?
Then notice that you have an extra "01" byte immediately following the in-counter?
These extra bytes are resulting in an invalid hash calculation.
But I tried getting the raw transaction from electrum wallet and chainquery.com, and they all have the long tail starting with 12...
They seem to be giving you the transaction in the extended serialiation format (witness serialization when there are witnesses).
This is actually incorrect and in violation of the segwit specification which states that the witness serialization for a non-witness transaction (as the coinbase transaction is) is the legacy non-extended (no witnesses) serialization format.The extra 0001 between the version number and number of inputs is the marker and flag bytes for extended serialization. The 012000... at the end of the transaction is an incorrect and invalid witness (it means that there is a witness of 1 stack item which is 32 bytes in length and all 0's. During verification, this would be pushed to the stack, but it is incorrect to have that there at all).Edit: That was wrong, explained in a post below.