Bart van Ingen Schenau's answer is correct as far as I'm concerned, but I wanted to add this as maybe an easier way to remember the distinction.
In the beginning of the process of having an application built, there is a person/team/company with a very specific need that needs to be filled (who I will call the customer). They are the best source of stating the requirements. They know what they need. However, they don't know how to find a solution for their need.
At the other end of the line, there is the software developer. They are the best source of solutions to problems. However, they don't know which specific problem currently is in need of a solution.
In some way, the customer needs to convey the specific problem to the developer, so that the developer can then find the right solution and report it back to the customer. There may be several layers of analysts between customer and developer, or the customer could be talking to the developer directly. In either case, there is room for misinterpretation of the requirements between customer and developer, and that's the main thing to remember here.
Using an example of miscommunication, let's say that the customer needs a tool to send marketing emails to many people at once, and the developer misunderstood and thought that they needed a tool to send many emails to one person.
TDD and BDD are something that developers do. They write the tests. Therefore; the developer is going to write tests to confirm their own understanding of what the problem is: does the application send many emails to the same person?
If they wrote their software correctly, the tests will confirm that the application indeed sends many emails to the same person. The verification has succeeded.
The developer will demo the application to the customer, who immediately sees that this tool does not send emails to many people at once, which is what they had asked for, and therefore the validation has failed.
The only way in which the tests written in BDD/TDD could be part of the validation, not verification, is if the customer is the one writing the test suite.
I've seen this happen once, where a software company hired another company to create a machine-learned algorithm. The customer company had gone through the effort of quantifying their requirements in a set of easy to run tests, therefore suggesting the developer company to use some kind of test-oriented development while also pretty much removing any room for misinterpretation of the requirements (barring silly things like building software that is hardcoded to only handle the provided test cases).