fetch: hold FetchTasklet mutex through deref_from_thread so HTTP thread is never the final deref - #32707

The comment at lines 2193-2194 ("we need to unlock before task.deref(); explicit unlock + deref at end instead of nested defers") now states the exact opposite of what this PR implements — `deref_from_thread` is now intentionally called *before* `mutex.unlock()` in both reachable paths, and the new comments at the deref sites explicitly say "Deref while still holding the mutex." This stale comment documents the buggy ordering as a requirement and could mislead a future reader into reverting the