For what it's worth, when we say we do TDD in my team, we write a singular test case that fails, then we implement the production code until the test case works. Then maybe do a bit of refactoring to make it all work nicely together, and only then you start with the next test case.
Writing swathes of unit tests upfront sounds absolutely mad to me, for the reason you state. But also because you do need an API to test against. You can't write a unit test in complete isolation, pretty much by definition. You can often do so for integration tests, but you definitely don't want to put all test cases into integration tests, as that increases complexity massively...
If there's no reason to hold the feature code back (i.e. its integration doesn't break anything), then it's much easier for development to ship the feature and disable it with a feature flag. Otherwise, you have two versions of the code, which means changes need to be integrated in both versions, which is largely just pointless busywork.