Query Frontend: out_of_order_results_cache_ttl does not fall back to results_cache_ttl

[Shvejan]

Describe the bug

results_cache_ttl and out_of_order_results_cache_ttl are both per-tenant limits.
If a tenant sets only results_cache_ttl and leaves out_of_order_results_cache_ttl
at its default of 0, cached results are split across two different TTLs:

• results outside the out-of-order time window → results_cache_ttl ✅
• results inside the out-of-order time window → global cache backend TTL ❌

So overriding results_cache_ttl alone silently fails to apply to recent data, and
that data instead picks up an unrelated global default.

Expected behaviour

out_of_order_results_cache_ttl should fall back to results_cache_ttl first, and
only then to the global cache backend TTL:

out_of_order_results_cache_ttl → results_cache_ttl → global cache backend TTL

Where

getTTLForExtents in pkg/querier/tripperware/queryrange/results_cache.go returns the
out-of-order TTL unconditionally when extents overlap the out-of-order window, with no
fallback when it is 0.

Note the fallback has to be resolved per tenant before aggregating across tenants,
since SmallestPositiveNonZeroDurationPerTenant discards zeros — otherwise a federated
query loses the information about which tenant left the value unset.