Top-10 auspicious DATES over the next ~3 months — CACHED (issue #773).

Same deterministic engine as /muhurat/electional (universal classical Choghadiya + Abhijit, minus the Rahu/Yamaganda/Gulika malefic windows; no activity-specific ruling asserted — §8.3), aggregated to the best window per DATE and ranked. The 90-day scan costs ~10.6s CPU per 30 days, so the result is served from muhurat_cache — one compute per (11 km location bucket, start date) per 24h, shared by every user in that bucket — instead of once per dashboard load. This is why the packet is NOT part of the dashboard bundle: the dashboard JS fetches it asynchronously after its own binds, so a cold miss can never delay the board render.

Per-day compute goes through the audited _dashboard_daily_panchang memo (same wrapper as /muhurat/electional), so an overlapping "today" compute is shared and the read-only consumption cannot mutate the canonical cache.

start_date is optional and REJECTED (422) outside [today-1, today+31] in the resolved timezone: it is part of the cache key, so an unbounded value would let a caller sweep it and turn every request back into a cold scan. Rejecting rather than clamping keeps the response honest about the range it actually computed.

DARK by default (owner ruling 2026-08-20, PANDIT_RATIFICATION_PACK Section I): with BDA_MUHURAT_TOP10_ENABLED unset/false this returns a clean feature_disabled envelope with ZERO compute — no timezone resolve, no cache touch, no astronomical core. It is a 200 with an empty top_dates rather than a 404 on purpose: the dashboard treats a non-OK status as a TRANSPORT failure and retries it on every re-bind (AUDIT D3-R), whereas an empty answer is memoised, so the card settles into its locked/missing state and stops asking. Machine-readable enabled: false lets an ops probe tell "dark" apart from "broken".