Symmetric key as proof of ownership of a session?
Because all requests are encrypted with the session key, can that act as a form of proof that the client is the real owner of the session ID? e.g. If the session ID somehow is stolen, it can still not be used to communicate to the backend as you still would need to have ownership over the shared secret.


That depends. I don't see any explicit check for this defined. I also don't see any specific mention of defusing replay attacks (in both ways, as there is only one encryption key, it seems). Also, 32 bit isn't much to avoid either integer overruns or collisions, so an attacker with another valid TLS key may retry until such an ID is created.


How much added security does this setup give if for some reason the TLS connection is broken into? (e.g. due to MITM, or because the TLS-level encryption is broken)


None, as you don't perform any authentication of or after the key exchange.


Does this setup aid in API obfuscation? E.g. client-side you can install software that - prior to TLS encryption occurring - can inspect all incoming and outgoing traffic. For my application, they would only see requests that are already encrypted. Is it easy to work around this?


No, it won't aid in API obfuscation, and yes, it is easy to work around this because of 2. And if you have an unencrypted part then an attacker can do an MITM there.
Better to just rely on TLS.