Yup, that's what I wanted to see (barring some formatting mistakes but it's good enough).Your drive has no LBA or sector-level issues. LBA 0 is perfectly readable/writeable from my perspective. That's good!
"So then what was that error in SeaTools, talking about sector 0?"
The error, in actuality, was self-induced by the software itself (i.e. a bug or a design mistake).
The error you saw was actually a direct result of what you see in your SMART error log. You can see clearly that roughly 10 hours ago (at power-on hours count 11246) a piece of software attempted to issue ATA command 0x37 (SET MAX ADDRESS EXT) to the drive, which the drive rejected (and a proper error status was returned). That particular command is usually used to modify the HPA region of a hard disk, which contains the advertised maximum LBA count of the drive (i.e. it's maximum capacity).
I'm going to skip all the low-level technical details of the ATA CDB decoding and so on -- yes, I really can read all of that stuff (it takes me some time along with reference materials, but I do understand it!), and yes really the below is the short/terse version! -- and instead try to summarise what happened:
1. SeaTools attempted to issue SET MAX ADDRESS EXT, specifically telling the drive *not* to change the advertised maximum LBA count/capacity if a hardware bus reset occurs or a power-on reset was encountered. (This is a safety net to ensure that if an I/O error is later encountered while, say, testing the drive during an extended/long test or surface scan, that the drive not actually retain that capacity change):
2. In the same command, attempted to set the maximum LBA count to a value which I cannot determine due to limitations of the SMART error log; the SMART error log only saves the least-significant byte of each CDB field, and some of those fields are actually much longer than 8-bits (some are 48-bit for example). So I can't see what it was truly trying to set the limit to, but it tried it. However, the error status (keep reading) indicates the software tried to set the capacity to something smaller than the native maximum LBA count.
3. The drive received the CDB successfully, but rejected it:
These registers decoded -- specifically ER -- indicates the drive returned 0x10 (bit 4 set). Bit 4 = IDNF (ID Not Found). This behaviour is fully 100% defined per T13/2015-D rev 3 specification:
If the Maximum LBA ... is less than the native max address, then the ID Not Found bit ... shall be set to one if a previous non-volatile SET MAX ADDRESS EXT command has been processed since the last power-on or hardware reset. ...
ST was 0x51, which means bits 0, 4, and 6 were set. Bits 4 and 6 are irrelevant to the situation, and bit 0 being set means an error condition occurred.
4. The same software that submit this CDB did not expect an error condition, and therefore erroneously reported a failure for LBA 0. Naughty naughty -- bug in SeaTools. :-)
So as I said further up -- your drive is perfectly healthy.
I should note, however, that you did not run an actual SMART-level long (sometimes called "extended") scan, which at the firmware level attempts a read of all LBAs and reports back any failures in the SMART self-test log along with an LBA number. You did, though, state that you "ran a surface scan test", which if I remember right, inside SeaTools, simply issues LBA reads from the OS (DOS) itself for every LBA and reports back any failures. That's perfectly fine to do and a good indication that every LBA is readable (and most certainly writeable).
So your issue with MBR problems, partition tables, etc. is something software-level and not disk-level.
Hope this sheds some light on things -- welcome to what engineers do. :-)
P.S. -- Consider yourself extra proud: this thread has given me an idea for a utility to write that would greatly benefit most of the Internet, when/if I have the time.--
Making life hard for others since 1977.
I speak for myself and not my employer/affiliates of my employer.