Neither of the problems you think you have are problems.
Spinning up multiple contexts isn't really a problem, thanks to connection pooling. Creating a new context doesn't actually need to create a new database connection, it just grabs one from the pool. If you're putting one back into the pool right before you're about to need a new one, instead of holding a lot of concurrent connections, this has very little overhead.
If you do pass around contexts between these methods its still not a problem. The code is asynchronous, but it is not doing anything in parallel. The context is only ever used by a single thread at a time. You're always awaiting any operation that would potentially be asynchronous, which means that while other code that is entirely related to these methods may be using the CPU, whether that be another response handler (if this is ASP), the UI pumping other events (if this is a desktop app), or something else, you're still not put in the position of accessing this context from multiple threads at once.