What is the overhead of GCM? And how are GCM tags signed by RSA/PKI?
If we're using the cyphersuite TLS_AES_128_GCM_SHA256; and GCM is using Encrypt-then-MAC (which appears to be always?) and is configured to use a 128-bit tag; and AES_128 is encrypting plaintext in blocks of 128 bits; then is GCM adding a 128-bit tag onto each one of those blocks (thus, halving the amount of cyphertext that can ultimately fit into the data payload of the L3 packet)?

No, the GCM is performed on the entire record; hence the overhead added by the GCM tag is 128 bits per record.  That is, the GCM encryption operation is given the plaintext (which is the original unencrypted record), the AAD (which is made up by the record header plus the record sequence number) and the nonce (the 8 bytes given in the record plus 4 bytes from the key negotiation step), and it produces the ciphertext (which is exactly as long as the plaintext) and a 16 byte GCM tag.  TLS doesn't worry about what GCM does to perform this operation.
The table you cite gives the overhead per record (however, it is mislabeled as per packet; TLS records do not correspond to 'packets'; there may be several records per TCP packet (segment), or a single record may extend over several packets).

How/where exactly is SHA and RSA (or any signature algorithm) used in this process?

SHA and RSA are not involved at all during the record encryption/decryption process, so none of your three options describe the situation.  They may be used (and generally are) during the connection set up phase (which verifies that the server is who he claims to be (and optionally the client as well), and also generates the symmetric keys that GCM uses.