It's a regression test, which is definitely TDD. The code in question is the fix for the bug, the test verifies that the bug is fixed and will remain fixed.
So any new changes/bugfixes you will make to this legacy codebase, first you will write a test and then make change. That's pretty standard. Many legacy codebases will have no tests and people who wrote the code will have left long time ago.
It's adopting test driven development during maintenance of an existing system. It's exactly TDD (identify need, write failing test, code to pass test.) TDD is a discipline that can be adopted at any time, not an SDLC that can only sensibly be adopted at the initiation of a project.
There's a bug, you write a test, "this bug shouldn't exist", that test currently fails, then you write just enough code to fix the test, then refactor. That's TDD.
Well, first of all, that's not TDD. TDD is Test-Driven Development. In your scenario, you wrote the test after the code in question. In TDD, the whole point is to write the test before the code in question.
So the value in your scenario is only insofar as the test is a useful way to quickly exercise the code in question. For example, if we have some sort of customer-facing website and there is a bug in how they save their user profile, it will be easier to test fixes to the problem if we don't have to go through the full flow of logging into the site, navigating to the profile, making edits, and clicking save all the time. But having an XUnit-style framework for running that test is not necessary for that.