Is iv[0:3] the fixed IV established from the handshake and iv[4:11] are the current (write) sequence number + 1?
Mostly not. In TLS1.2, the GCM nonce is 4 bytes generated from the handshake plus 8 bytes in (the beginning of) the transmitted record. The sender must make this 8-byte nonce_explicit unique, and some implementations make it a counter because that's a cheap and safe way to make it unique. (Unlike IV for CBC it does NOT need to be unpredictable.) In TLS1.3 for GCM the nonce is 12 bytes generated from the handshake XORed with the (8-byte, right-aligned) sequence number.
For TLS 1.2 the additional data is type || legacy_record_version || length
No; it is seqnum || type || version || length. (In 1.2 the record header version is the real version; only in 1.3 does it become legacy.)
But for TLS 1.3 the additional data is seq_num || type || legacy_record_version || length?
No again; now it's type || version || length using the 'opaque' (outer) type (not the one within the encryption), the 'legacy' (record header) version, and the length including the 'hidden' (inner) type and any padding plus the AEAD algorithm's 'expansion', which for rfc5116-style GCM is the 16-byte tag. Because nonce now depends on seqnum always regardless of ciphersuite and AEAD protects nonce, seqnum isn't needed in AAD.
