How is this "captive portal" intercepting and manipulating my HTTP requests?

So my question is, is this a "man in the middle" type interception at the TCP/IP level?

Yes, this is a man in the middle type interception which is easy for the access point because it is actually in the middle of your connection to the internet. Such redirects to the capture portal are easily done with a packet filter.

The usual way is that once you've authorized (logged in, accepted terms, whatever...) a temporary rule will be added to the packet filter of the access point which takes preference to the redirect rule and allows direct access to the internet.

When make a HTTPS request The request outright fails - I'm assuming because my computer won't accept a connection from a remote host it can't authenticate?

It seems they aren't even trying to intercept your HTTPs connection and instead are just blocking it.

Some captive portals will try to intercept the HTTPs connection resulting in a certificate error in your client.

I've also seen some captive portals that let HTTPs though even for unauthenticated users.

So my question is, is this a "man in the middle" type interception at the TCP/IP level? in other words, when the network stack on my computer tries to establish a TCP connection with the placeimg.com server, by starting a 3 way handshake, is the Wifi services gateway or network node responding to my SYN with an ACK/SYN and saying yes I'm that server you wanted to talk to - lets complete our TCP connection, then once established its pre-programmed to automatically send the HTTP redirect and then, because my browser is actually generating the next request to 1.1.2.1 itself - all the "funny business" can stop and its all normal HTTP/HTML behaviour from that point forward. (ie. standard form filling and submissions as you would on any normal website)

Yep, that is the normal way to do it. If the captive portal server is linux based the "REDIRECT" or "DNAT" targets can be used to divert your traffic to the captive portals webserver which can then issue the redirect. Other stateful firewalling systems likely have similar options.

These systems are generally pretty flexible, so if the portal operator wants to offer access to particular parts of the internet (for example a payment gateway so you can pay them) without authentication they can easilly do so.

When you authenticate successfully the captive portal can put in place a rule that overrides the redirection rule allowing you normal access to the internet.

Note that any (non-secure) cookies set for the website you tried to visit will be sent to the captive portal webserver. It's up to the implementer of the captive portal whether they actually do anything with them.