Firstly, definitions and implementations of test types are different depending on who you ask in the industry, but unit tests should only test a single module - That is pretty much the only agreement on testing between different Developers and Languages that I have seen. That said, Microsoft have a good definition guide.
As you state, End-to-end (E2E) tests generally use "live" but "dummy" data, usually from a test environment like SIT or UAT. Your team chose to automate those tests - they probably have good reason. In my experience, at least for medium sized projects and smaller, it is more common that those types of tests are performed manually, and more often by QA. However, this is somewhat tangential to your question.
I believe what you really want are Systems Tests.
Unit Tests -> Integration Tests -> Systems Tests
Systems Tests are tests that generally test an application endpoint (HTTP controller, CLI command) response with a simulated client request, using either mocked dependencies (speed, simplicity) or test harness dependencies, like an in-memory database (accuracy).
Thus you get the benefit of executing a request, which travels throughout the entirety (or most of) your application, not actually using live data, and returns a response, which you can test against.
Understand however, that it is a trade-off.
You gain speed in testing that your applications framework returns a response as you expect, but simultaneously it is somewhat brittle, because mocks by their nature are not always accurate.
A live dependency could at any time, change its data structure or fix issues which impact responses - which your mocks won't account for until someone manually discovers that change.
Depending on the application, the delay in discovering that your test suite of mocked dependencies that is passing as all green, doesn't actually match reality, might be unacceptable.
That reason could be why your team chose to use automated live E2E tests.
