Return -1 for missing historical fiat rates on given day

[cranycrane]

Problem

When a historical fiat rate is requested for a timestamp whose day has no stored rate, Blockbook does not report the data as missing — it silently serves a rate from a different day:

• GetTickersForTimestamps (fiat/fiat_rates.go) forward-scans across missing days to the next available daily ticker.
• If no later daily ticker exists at all, it falls back to the current ticker — so in the worst scenario (historical fetching failing for days or weeks), a request for a weeks-old date returns today's price.
• The DB token path (getTokenTickersForTimestamps) has the same current-ticker fallback.

Today the -1 sentinel in API responses only means "currency/token not present in the resolved ticker". A missing day is indistinguishable from a valid answer unless the client compares the returned ticker timestamp against the requested one — which clients generally don't do.

Proposed behavior

A historical lookup should serve only the ticker stored for the resolved UTC day. If no rate is stored for that day, return -1 instead of a neighboring/current rate. Timestamps newer than the stored history should keep returning the current ticker (unchanged).

Case	Current	Proposed
Rate stored for the day	exact rate	exact rate (unchanged)
No rate stored for the day	closest later day / current rate	-1
Timestamp after stored history	current rate	current rate (unchanged)

Affected endpoints: /api/v2/tickers, /api/v2/multi-tickers, and fiat rates in balancehistory.

Why this is still relevant after #1560

The #1560 rework (startup self-healing reconciliation, CDN-routed historical fetches, 429 resilience, split current/historical loops) made long whole-day gaps much rarer, but it is a write-side mitigation — the read-side semantics are unchanged and gaps can still occur:

• reconciliation runs only at startup; runtime fetch failures on a long-lived process are not repaired until restart,
• gaps older than the 365-day reconcile window are never repaired; trailing gaps over 90 days are reported rather than refetched,
• partial-day holes (a day record exists but lacks a specific vsCurrency or token series) are invisible to the key-only reconcile scan and still resolve to a neighboring day's rate — see the write-side analysis in fix(fiat-rates): if historical rate missing for given date, return -1 #1545 (comment).

Returning -1 is the read-side half of the fix: it stops silently-wrong reads regardless of how fast any write-side repair catches up.