I'm not in software development, but I've encountered similar challenges in my field.
It's one thing to supervise somebody in an area which you know well - "if Bob was sick tomorrow, I could take over his job, and do it better than him". It's quite another when you move far enough up that you can't be across all the technical minutiae, for the kinds of reasons that you mention.
It might be helpful to think of it as not so much "letting go" as "increasing abstraction".
When you're writing a simple program, you might code the whole thing yourself; you might understand what every single part of the program does and how it works. But past a certain level of complexity, that becomes inefficient and unsustainable. If I want to invert a matrix, I could code that myself, but it makes more sense to use a numerical library that somebody else has already written. If I want to use weather data, rather than trying to build my own weather station and link it into my code, I'm probably better off figuring out how to use an API to get that from some external source.
As a developer, you've probably spent a lot of time learning how and when to do that abstraction. Probably a lot of your work is not in coding new stuff from scratch, but figuring out how to assemble components that abstract away the messy details, so that you don't have to cram an impossible amount of detail into your brain and do an unreasonable amount of work.
Moving into technical leadership is a bit like that, IME - but instead of abstraction via code libraries and APIs and modules, you're trying to achieve abstraction via delegating people.
Impostor syndrome is a big risk here. One of the most popular tropes in office culture is the idea that managers are ignoramuses, and when you're used to measuring yourself by technical proficiency, it's easy to feel like you're becoming that stereotype. So you need to find new, more relevant metrics of success, which mostly boil down to "am I helping my team do their job?"
When you're delegating work well, and each member of the team knows what their job is, you may find that being on top of the technical micro-detail isn't important as it once was. The small stuff goes rusty quickly with disuse, but a lot of the higher-level skills remain. Now and then I've been able to debug other people's code over the phone, in languages I've never learned, just by drawing on my experience of the kinds of things that often go wrong and the kinds of methods that are effective for identifying them. ("What did you change?" "Why don't you run it up to this point and check whether the problem is before or after that step in the program?" etc. etc.
I know that's a bit rambling, but maybe there's something in there you can use.