ok! One problem identified and resolved - the "No EEPROM/flash device found."
It turns-out that no on-board circuitry was damaged in connecting the external flash programmer. Instead, this Samsung Chromebook 4, model XE310XBA-K01US, revision 1.0 motherboard, is *missing* the four series resistors connecting the H1B2C Google Security Chip to the GigaDevice 25LQ128D boot flash memory device. Consequently, the Serial-Out line always remains in the pulled-up high state, and the GSC sees all 1's. Only the Gemini Lake SOC SPI bus is connected to the boot flash device. The simplest solution is to solder-bridge the pads for these 0402 size resistors, which then allows Closed Case Debugging to function as expected.
More generally, it seems that manufacturer implementations of Google reference designs can be quite variable. Some boards do not include the separate SPI bus multiplexer chip shown in presentations on the GSC, and instead, directly connect the GSC and SOC tri-state GPIO lines and provide pull-up resistors. And, as in this case, some manufacturers do not even connect the GSC to the boot flash memory device.
As I understand, manufacturers are not suppose to leave the GSC disconnected from the SPI bus to the flash device. However, also, apparently there are no legal constraints associated with the "Chromebook" trade name requiring Closed Case Debugging to be functional. It would be useful to keep track of these "problem" Chromebooks.
I haven't discovered the cause of my difficulty with the external flash programmer. I note that the Not-Write-Protect and Not-Hold lines are not part of the basic 4-wire SPI bus, and I have not found documentation about how these lines are driven. It may be that their default state depends upon the Closed Case Debugging permissions. But now, with CCD working, the external programmer is not needed.
So, I can get back to debugging my u-boot payload.
James