Avoid redundant timezone request for range history

[JonArnfred]

Summary

• Defer ticker timezone lookup for range-based history requests.
• Read exchangeTimezoneName from the requested chart response and persist it in the timezone cache.
• Preserve the pre-request timezone lookup for explicit dates, period="max", and repair paths that require timezone-aware date conversion.
• Restore request-count regression coverage using transport-independent mocks compatible with curl_cffi.

Why

On a cold timezone cache, Ticker.history(period="...") currently initializes PriceHistory by making a separate range=1d chart request to discover the ticker timezone. The requested history call then makes another chart request whose metadata contains the same timezone.

This means an ordinary range-based history call makes two chart requests when only one is necessary. The extra request increases latency and Yahoo request volume, particularly for bulk downloads of previously unseen tickers.

The one-request behavior was previously covered by #1215, and avoiding the separate timezone request was also discussed around #1076 and #1112.

Behavior

Range-based calls now obtain and cache the timezone from their own chart response:

yf.Ticker("AAPL").history(period="5d")

Calls that need the exchange timezone before constructing request timestamps retain the existing lookup behavior:

yf.Ticker("AAPL").history(start="2024-01-01", end="2024-02-01")

There are no public API changes.

Testing

• Added an offline regression test asserting that a cold-cache range request makes exactly one chart request and caches the returned timezone.
• Added a companion test confirming that explicit-date requests still fetch the timezone before converting dates to epochs.

[ValueRaider]

Passing getter and setter as arguments is bad. Need refactor: move _get_ticker_tz and _fetch_ticker_tz into utils.py. Might be time to split-out some of utils.py into price_utils.py