Q2: On to the Sprite Attribute Table... Why is the top ROW of y-pixels located a -1 when the leftmost COLUMN of x-pixels are located at 0?
The top left pixel position is (-1y,0x)? Why not 0y,0x?
This has to do with time and memory access. The 9918A is a scan-line based device, i.e. it only figures out what needs to be displayed on the screen one scan line at a time. Without going into the gory details of it all, there is a lot going on during a scan line to get the picture drawn on the screen. Figuring out what sprites to draw on a scan line takes quite a bit of time, and so the VDP does a lot of the sprite processing *during* the current scan line, which means the sprites appear on the following scan line.
For example, during scan line 0, the sprite list is processed and sprites with a Y-coordinate of 0 are remembered, up to a limit of 4-sprites since that is the max number of sprites the VDP can put on a single line (there are only four sprite shift registers). During the horizontal blank period, the pattern data for any of the sprites found on that scan line (scan line 0 in this example) are loaded into the sprite shift registers. The shift registers are used during the next scan line (which would be scan line 1 in this example) to provide the pixels that make up the sprite. So during scan line 1, the sprites for scan line 0 are shifted out, while sprites for scan line 1 are being determined.
Thus, spites always show up one line after their specified Y-position. So to get a sprite on scan line 0, it needs to be processed on line -1, which is the same as a Y-position of 255. Higher level languages can hide this from you, but when working directly with the hardware you have to deal with it yourself. Also note that the collision flag will also be off by 1 line compared to a sprite's Y-position as well. That is because collisions are detected by the VDP during scan-out of the pixel data from the sprite shift registers.
Q9: Lastly, is the EC something I need to manage (endlessly setting and clearing and setting...) throughout my code? Is this normal or is it either set or cleared upon initialization of the VDP registers at startup?
I think you are realizing this. You have to manage the early-clock bit in your own code, and update the sprite table if you want to have sprites that can move in from the left of the screen. It is a pain, but that is just how it goes on the old systems. Lots of limitations. The 80's era of coin-op arcade machines were similar, since most of them were 8-bit machines but the screen resolutions were consistently more than 256 pixels wide. So they had to deal with a 9-bit X-position on an 8-bit computer. In a sense, the early-clock bit is just like that. You are dealing with X-positions that are greater than 255, so you have to manage that yourself.
The easiest way to deal with it is to keep your sprites confined to the visible display and don't "slide in" from the left. You don't have this problem in the Y direction because there are only 192 visible lines, and that easily fits into the range of a single byte, with enough range left over to slide in and out from the top and bottom of the active display.
As for a default setting for the bits, there is none. The sprite attribute table is in VRAM (not VDP registers), which is made up of DRAM chips, and the contents of DRAM at power on or reset is going to be random. It is up to you, the programmer, to initialize all your VDP table data, as well as the VDP registers. Don't assume anything and you won't have any surprises.
**** The 32-bit shift is performed by hardware.
Everything dealing with the 9918A is done in hardware. It is a task-specific IC and does not have a CPU or any kind of "processing" capability in the general sense. It consists of a bunch of counters, shift registers, fixed state machines, and random logic. Also, technically, in the case of the 32-bit shift of the early-clock, no shift of the data actually happens. It is literally allowing the clock signal to the sprite shift registers to happen early in the scan line, hence the name "early clock". If the sprite shift registers start shifting early, then the sprite appears sooner during the scan line.
You can also just think of it in the logical sense without knowing the technical details about how it works. You have one byte for a sprite's X-position, so 0..255, and you also have 0..255 visible screen positions. With the early-clock bit set to 0, the X-position has a range of 0..255, i.e. an unsigned byte. With the early-clock bit set to 1, the X-position is partially signed and represents X-positions from -32..223. The visible screen is always 0..255, so just map accordingly.