Route pet asset downloads through the shared HTTP client (#36008)

## Why

Built-in pet downloads used a standalone blocking client, so CDN redirects did
not use Codex's configured route handling.

## What changed

- Download pet spritesheets asynchronously with a reusable
  `RouteAwareClientPool`.
- Keep cache validation, asset installation, and pet decoding off the async
  runtime while sharing one asset-and-load path across startup, previews, and
  selection.
- Preserve the download size limit while consuming streamed response chunks,
  and remove the TUI's direct `reqwest` dependency.

## Testing

Add coverage for oversized response chunks, cached built-in assets, pet loads
without an existing Tokio runtime, and stale preview and selection completions.

GitOrigin-RevId: 725e76f3ddb7e84b7212769892f28dc0add15741

codex-rs/deny.toml

@@ -245,7 +245,6 @@ deny = [
         "codex-otel",
         "codex-protocol",
         "codex-responses-api-proxy",
-        "codex-tui",
         # Third-party crates that own their reqwest integration. These are not part of the
         # first-party migration count above.
         "oauth2",