There may be extensive damage in this case, both ME and BIOS I mean. It could be BIOS mostly. Try a CMOS, if not possible then restore default BIOS settings. Then, make sure that the option "Enable ME Reflash" is Disabled at the BIOS. After a reboot, does the problem persist? Run fptw -d bios.bin -bios and attach the resulting file here.

Gigabyte usually leaves the Flash Descriptor unlocked for easy service (the downside is easy bricking as well if something goes wrong) and that is verified by the fact that their own BIOS updater batch script uses FPT to update/reflash the entire ME region which requires read/write access there and thus an unlocked flash descriptor. Why you get Error 26 in this case, I'm not sure yet. We should see if the BIOS is ok first and make it stable with settings being kept and not removed upon restart as you say.

The flash descriptor is corrupted, it's addresses are all the same and invalid. Flash Descriptor is 4KB at the beginning so for example it should have a base (start) of 0x000000 and a limit (size-0x1) of 0x000FFF as 0x1000 = 64KB. I assume fpt is trying to access an invalid location based on what it reads from the FD. Since the FD is corrupted, FPT cannot be used with region-specific commands such as -desc, -bios, -me etc. So, let's try a test with the commands below which should dump the sections manually (based on X5BF.D07 image from Gigabyte):

fptw -d desc.bin -A 0x000000 -L 0x001000
fptw -d me.bin -A 0x001000 -L 0x1FF000
fptw -d bios.bin -A 0x200000 -L 0x600000

Regarding ME, these is no way you have ME10 firmware flashed, the platform wouldn't even post. You still have ME9.1 firmware, maybe the logs point to the drivers being updated to v10.x, definitely not the firmware.

The fpt version you are using is correct, admin rights should not matter for this procedure. So the command fptw -I shows those aforementioned (corrupted) FD addresses? I'm asking because the fpt -I output I know looks a little different but it could be that I'm testing on older platforms.

Although I highly doubt it will be of any help in your case, try fptw -greset command and check status after the system boots up again. The long bootup probably has to do with the ME not initializing properly and entering recovery mode or similar.

Other than that, I can't think of something else. If we can't use software tools to read or write to the SPI chip because the FD is messed up, the only solution is a hardware programmer or free service in case it's under warranty as the problem occurred with their own update procedure.

Why are you using MEInfo v10 on a system with v9.1 firmware? These are not compatible. Use the latest MEInfo v9.1 that I have uploaded at the System Tools found at the first post of mine.

The ME recovery mode is not related to the AMI recovery mode. So ctrl+home or other such hotkeys don't matter for ME itself but for the BIOS.

So no matter what you type at FPT, you always get the Error 26? Mmm, it could make sense. Even for a "simple" command such as -greset, FPT has to read and write a byte which triggers the reset. Maybe it cannot even do that because it doesn't know where to write. Similar for -I as it has to read? Maybe. Honestly I don't have currently that much knowledge/experience to really understand what's going on. At this point, this problem looks more like a general SPI image corruption and less ME-related.

If the problem is indeed a BIOS one (doubt it, the FD should not look like that, FPT should be able to work at a basic level) then yes, you may be able to restore it via the AMI BIOS Recovery, provided that you know the filename. Maybe ask Gigabyte or search around for other users with the same system? I know PhoenixTool suggests some recovery names for some BIOS but I'm not sure if it will work in your case.

1) To my knowledge, AMI BIOS Recovery deals only with the BIOS and not the whole SPI image. It may depend on OEM implementation but I wouldn't know what stands true in this case.
2) For each platform you can use only the same major.minor tool versions. For ME9.1 you need 9.1 tools, not 10.0, not 11.0 or so. The only exception is ME7 with ME8 tools but that's irrelevant here. There are no "other" versions of FPT. FTK includes what is posted here, it's even said by CodeRush himself at the github readme. He may not have updated the versions used at FTK but that doesn't make them more compatible with given systems or "different", just older and possibly buggy with less features etc.
3) As far as Intel tool error codes, do not trust them. Sometimes unexpected errors show after irrelevant changes. For example removing the contents of fparts.txt results in a "admin rights required" error which is completely irrelevant in reality. It just thinks that it cannot read the file because it's empty. So no, admin rights are not needed for it to work but you can always launch it as such, noone is saying that's not a good practice in general.
4) The problem is not with fparts.txt, the chip info are correct. The size is correct (8MB), the chip block erase (20) is correct etc as can be seen at the official specs. By removing the spi chips from the fparts.txt file you neither gain nor see anything new. It tells you that it cannot detect your SPI chip, simply because it was removed from it's database. The HSFSTS register may not rely at fparts.txt at all, read the SPI Programming Guide found at the System Tools v9.1 package and search for HSFSTS to learn more about it.
5) The problem is not with FPT or fparts.txt, you saw the output of AFU: garbage. It cannot read data if it doesn't know where they are located. Another sign of a corrupted Flash Descriptor. The goal is to dump the firmware. Try some other BIOS dumping tools which do the same job, even though I suspect you won't see anything different. Maybe that Universal BIOS Backup tool or something newer. I'm not following such 3rd party tools as FPT has been enough for Intel systems.

Newer version of the ME tools will report the "platform not supported" error. I don't know if Intel forgot to error it out at v10 but if, for example, you run the v11 MEInfo, there is no way you won't see that message. Based from experience I can tell you that using the latest tool versions of the same generation is the way to go. Anyway, that's not important right now and off-topic.

Another reason I don't believe FPT is the cause: Gigabyte includes it at their own BIOS release. They know it works, they have flashed the same way, a lot of people using that system have flashed that way properly. That cannot be true unless FPT and it's SPI chip database are working just fine for the system in question. Also, all three fpt included at the latest BIOS (DOS, Win32, Win64) are exactly the same as the ones found at any ME9.1 package after 9.1.10.1000 which is the last time they were updated. The hash is identical, nothing different. Moreover, the OEMs use that same version of FTP, there is no OEM-only version. These are all valid facts after almost two years of "research". Seeing that text inside the spoiler tag, I have to ask though: What exact tool (link) showed the text "THIS IS A DEBUG VERSION! NOT FOR DISTRIBUTION"? I'm curious as I've never seen that in any Intel tool so far. It makes no sense to me.

The BIOS options don't matter anymore. "Enable ME Reflash" would only make sense if it was a) visible at the BIOS and b) set to Yes, Enabled. So that's not any more helpful at this point.

For other software flashers/dumpers with their own SPI database etc, a very well known one is flashrom. Definitely give it a try.

Your system comes with a desktop BDW cpu, not HSW as I thought. ME10.0 is targeting BDW mobile (LP) but I suppose it works for BDW desktop as well. That's why it partially works and doesn't show "unsupported platform" error. The debug text seems to exist at all ME9.x and 10.0 FPTs so it's normal, I just hadn't noticed it before. The hashes between fpt, fptw and fptw64 are different of course as they are compiled for DOS, Windows x86 and Windows x64 respectively.

I can't really understand what you mean by wrong fpt commands/chip or what's the correlation with fparts.txt. Based on what AFU is dumping, it cannot read the chip properly as well. If it cannot read then it cannot write of course. It's obvious that it cannot read properly, otherwise the system wouldn't even post with such SPI chip contents (repeating garbage). Generally, keep in mind that /GAN can be buggy for some configurations and can result in unexpected results. It was worth a try but didn't really lead you anywhere.

I cannot understand what happened and the system is so messed up. I cannot understand how it still works to be honest and at what state it's at. Do you know what exact update package caused this issue from gigabyte? It must exist somewhere. Regarding the shutdown, I think the ME shuts down the system after 30 minutes in case of an unsupported configuration so maybe that's what you are seeing.

Try flashrom, your chip seems to be supported. Finding pre-built Windows binaries for it is not easy but try what's attached, maybe it works. For me it doesn't, says no supported EEPROMs found. It's probably the Windows build being broken but I don't use it so I don't know.