[Fire HD 8 and HD 10 Original Android Development] chairmanmiaow:
Well I've had a good poke around the partitioning and setup of mmcblk0 on a "good" and "bad" suez tablet for comparison and it looks like - unsurprisingly - there's probably considerably more to it than just dd'ing a recovery partition or two. For example:

"good" suez 😇

suez:/ # ls -alh /dev/block/platform/soc/11230000.mmc/by-name/ | tail -n +4 | awk '{print $8,$9,$10}'
MISC -> /dev/block/mmcblk0p9
PMT -> /dev/block/mmcblk0p2
boot -> /dev/block/mmcblk0p11
boot0hdr0 -> /dev/null
boot0hdr0_real -> /dev/block/mmcblk0boot0p1
boot0hdr1 -> /dev/null
boot0hdr1_real -> /dev/block/mmcblk0boot0p2
boot0img0 -> /dev/null
boot0img0_real -> /dev/block/mmcblk0boot0p3
boot0img1 -> /dev/null
boot0img1_real -> /dev/block/mmcblk0boot0p4
boot_amonet -> /dev/block/mmcblk0p16
boot_x -> /dev/block/mmcblk0p11
cache -> /dev/block/mmcblk0p14
dkb -> /dev/block/mmcblk0p4
kb -> /dev/block/mmcblk0p3
lk -> /dev/null
lk_real -> /dev/block/mmcblk0p5
metadata -> /dev/block/mmcblk0p8
proinfo -> /dev/block/mmcblk0p1
recovery -> /dev/block/mmcblk0p12
recovery_amonet -> /dev/block/mmcblk0p17
recovery_x -> /dev/block/mmcblk0p12
reserved -> /dev/block/mmcblk0p10
system -> /dev/block/mmcblk0p13
tee1 -> /dev/null
tee1_real -> /dev/block/mmcblk0p6
tee2 -> /dev/null
tee2_real -> /dev/block/mmcblk0p7
userdata -> /dev/block/mmcblk0p15

"bad" suez 🤕

suez:/storage/93CF-1B05/fireN # ls -alh /dev/block/platform/soc/11230000.mmc/by-name/ | tail -n +4 | awk '{print $8,$9,$10}'
MISC -> /dev/block/mmcblk0p9
PMT -> /dev/block/mmcblk0p2
boot -> /dev/block/mmcblk0p16
boot0hdr0 -> /dev/block/mmcblk0boot0p1
boot0hdr1 -> /dev/block/mmcblk0boot0p2
boot0img0 -> /dev/block/mmcblk0boot0p3
boot0img1 -> /dev/block/mmcblk0boot0p4
boot_x -> /dev/block/mmcblk0p11
cache -> /dev/block/mmcblk0p14
dkb -> /dev/block/mmcblk0p4
kb -> /dev/block/mmcblk0p3
lk -> /dev/block/mmcblk0p5
metadata -> /dev/block/mmcblk0p8
proinfo -> /dev/block/mmcblk0p1
recovery -> /dev/block/mmcblk0p17
recovery_x -> /dev/block/mmcblk0p12
reserved -> /dev/block/mmcblk0p10
system -> /dev/block/mmcblk0p13
tee1 -> /dev/block/mmcblk0p6
tee2 -> /dev/block/mmcblk0p7
userdata -> /dev/block/mmcblk0p15

I think at this point just to save time/effort it's time to reset back to stock and redo unlocking the bootloader from scratch again. It's worth double checking first of course but it does seem that it's still possible to unlock even the latest official Amazon suez firmware. Bit of a pain in the ass but it's entirely my fault - I know how fragile these things are but still half-arsed the TWRP upgrade even though I had misgivings at the time.

@8bitword - if you just want to get back to stock you can indeed just flash straight over the top of your existing system and basically fully recover. In your case you didn't even have the unlocked bootloader status or custom recovery setup to lose in the first place so you're just replacing a lightly mangled stock os with a fresh minty stock os. I need to comb through the other suez threads first just to refresh my memory on how to reflash stock though - I think you just put it in fastboot mode and then you can send the stock bin from a PC via adb or odin/fastboot.

Can anyone save me the effort and remind me?