Unexplained sustained space used in the TempDB log file
Is it possible for tempdb log space to not be reclaimable for hours even if there are no sessions running for anywhere near that long?

While it's probably possible, I would say under normal circumstances the answer is no.  In the absence of long-running transactions or long-lived sessions, the tempdb log should clear pretty quickly.

What caused tempdb log space used to suddenly free up 3 seconds after the above error messages (not enough space on disk and tempdb transaction log is full)?

The most likely explanation is that there was a long-running transaction.  It finally encountered this error and was killed, which allowed the log space to free up.

Is sp_WhoIsActive logging not enough to capture what process was holding onto the tempdb log space, what other additional logging can I do?

I would expect that to capture it.  One thing that might have caused you to miss it is if the process had executed statements in a transaction and then just stopped doing anything (without committing, rolling back, or disconnecting).
This would be the case if someone ran a query in SSMS that used a ton of tempdb, and then just left that SSMS window open all day.  These queries (that are holding resources, but not doing anything actively) won't show up in sp_WhoIsActive by default.  You need to add the @show_sleeping_spids = 2 option to see those.  Here's an excerpt from the built-in docs:


If the tempdb log space used was actually reclaimable but a glitch in SQL Server prevented it from clearing out, is there a T-SQL command I can run to try and free up available space in the log?

Not that I can think of.  You might try issuing a CHECKPOINT, to force the VLFs to clear:
USE [tempdb];
GO
CHECKPOINT;