If you think you can't test without requirements then you don't understand the purpose of tests.
I'm in a funny situation.
No you aren't. This is typical of many shops that use TDD.
To give you a sense of the environment, when we were using SCRUM, we would often intentionally commit to only 50% of our maximum workload, with a full expectation that the remaining 50% would be filled with quick response work.
I've been in shops where that was generous. It's a different world when you have operational systems with up-time requirements. Scrum and TDD still work fine if you do them right.
However, I find myself regularly faced with situations that do not have testable requirements until the majority of the work is completed. Because of the rapid response nature of the job, finding the solution that can be done is more important than holding to an arbitrary API picked at the start of the task. It's of no use to my customer if I can build their dream API in a month, when they need to have a working product in a week. The API only really gets finalized after we understand how the code is actually going to do the task.
Who convinced you keeping a death grip on an API regardless of your needs was traditional?
In situations where testable requirements are hard to come by, has anyone had success leveraging TDD in a meaningful way, even if it's not the "traditional" way?
I have had success with TDD when the only requirement I had was, "I wonder what this thing does".
Tests are not requirements. You might have a requirement. You might write a test that proves that requirement is met. You might even mention that requirement number in the comments of the test (or, God help us, in its name). Fine. But if that's all you're doing with tests you don't know what you're doing. Tests are for more than that. Much more.
I write tons of tests. More than I ever even check in. Why? Because tests help me read code. I write up test after test and watch my understanding of what I can do grow and grow. I change code and I change tests, rapidly. Because I'm learning. The tests lock down what I comprehend now. They remind me what I was doing when I come back from the bathroom.
So yeah, sometimes I write tests without ever looking at or thinking about a requirements document.
I dump a bunch of tests as my understanding grows. I find better ways to express what I'm trying to say. Just like I come back to this answer and rewrite it and move things around I do the same to my code and my tests trying to find the best way to express an idea. Not because the CPU needs me to. Not because requirements demand it. Not because TDD told me to. Hell I was doing this before TDD was a thing. I do it for the humans. I'm looking for the best way to present an idea so that the clueless newbie that comes after me can easily find the one line they need to change because the world changed after I left. I do that by using code and tests to tell the story of the idea well.
The purpose of tests is to help people read code.
They show what it does, what it needs, how much code you have to read to understand what is happening, but they don't tell you what you need. Your needs will change when the tests haven't been touched. It's up to you to decide if the code does what you need. Not the tests.
When you do figure out some requirements you can write other tests for them. You can show them off to your product owner. You can even put them in a special place so you can tell them apart from the ones you just write to help yourself read the code. That's BDD.
So don't complain that you can't write tests because your requirements are up in the air. That describes over half of everything I've done using TDD. Any code you write can be put under test. That test is "I think the code will do this, let's see if it does". That tells future coders (including me) what I was thinking. But deciding if that is needed isn't the tests job. That's yours. If you change your mind it's time to make changes. Change the test and then change the code. That's TDD.