Refactor blocking Python code to async without breaking it silently

Refactor the code below from synchronous to async — but only where it actually matters. Do not prefix every function with async def reflexively; that adds overhead without benefit for CPU-bound code and creates a false sense of concurrency that doesn't actually exist.

CODE
def fetch_all_prices(product_ids: list[str]) -> list[Price]: loops and calls requests.get() per id

I/O OPERATIONS INVOLVED
HTTP GET requests to a pricing API, a write to a local CSV file

GOAL
fetch prices for up to 50 products concurrently instead of one request at a time

DEPLOYMENT CONTEXT
Runs inside a FastAPI request handler, which already has its own running event loop.

REQUIREMENTS
1. For each I/O operation, identify whether an async-native library exists (httpx's AsyncClient instead of requests, an async database driver instead of a sync one, aiofiles for file I/O) and use it. If no async equivalent exists for something in HTTP GET requests to a pricing API, a write to a local CSV file, say so explicitly and wrap it with asyncio.to_thread rather than calling it directly inside an async def and silently blocking the event loop.
2. Any genuinely CPU-bound work (parsing, computation) stays synchronous, or is offloaded to asyncio.to_thread or a ProcessPoolExecutor if it's heavy enough to matter — making it async def alone does nothing for CPU-bound code, and pretending otherwise is the most common mistake in this kind of refactor.
3. Use asyncio.gather, or a TaskGroup on Python 3.11+, to run independent I/O calls concurrently where fetch prices for up to 50 products concurrently instead of one request at a time calls for it — don't await a list of calls sequentially in a loop and call that async.
4. Propagate cancellation and timeouts correctly: wrap calls that should have a deadline in asyncio.timeout(...), and don't swallow asyncio.CancelledError with a bare except Exception, since that breaks cooperative cancellation for whatever is awaiting this code.
5. Confirm Runs inside a FastAPI request handler, which already has its own running event loop. actually supports the change — code running inside an existing event loop (a web framework request handler) needs different treatment than a standalone script that will call asyncio.run() itself, and mixing the two incorrectly is a common source of "RuntimeError: this event loop is already running."
6. Every function whose signature changes from sync to async must have every one of its callers updated too — list them, don't leave a caller doing result = my_func() on a coroutine it never awaits.
7. If any resource used inside the refactored code (a database connection, an HTTP client session) is currently created once and reused across calls, preserve that lifecycle in the async version too — don't silently open a new httpx.AsyncClient per call inside a hot loop just because the sync version's requests.Session was easy to drop, since that trades one performance problem for a worse one.

OUTPUT FORMAT
1. The refactored code.
2. A table: function name, sync or async now, and the reason.
3. Every caller found that also needed updating, and confirmation each one now awaits correctly.
4. One line confirming any shared resource's lifecycle (created once vs. per call) matches what the original synchronous code did, or naming why it deliberately changed.