Forward-looking, bucketed read. filters.time_range.start_date is ignored -- the series
always begins today (or later, if the stored forecast is stale); only end_date optionally
caps how far out it runs. Fiscal period resolution uses dates the service computes itself
(see TokenomicsService.get_forecast_results), not the caller's start_date -- which is why this
does not reuse the shared _validate_fiscal_trend_interval validator usage/adoption trends
use: that validator requires a full time_range for a fiscal interval, because those endpoints
are reading a historical, caller-defined window. Forecast has no such window.
filters uses the fiscal-capable filters, so time_range has no window cap. The 128-day
horizon already bounds the response. A fiscal-year-to-date request runs from today to the year's
end, and in a 53-week fiscal year that range can exceed the 366-day read cap.
leader_user_key is deliberately accepted under BOTH views, matching
/tokenomics/v1/team-rollup: it selects which team's forecast to read, while view selects
which authorization rule proves the caller may read it (organization view -> any manager in
the directory; team view -> only managers inside the caller's own subtree). Requiring
view="team" would force every team read down the team branch, which resolves the caller's own
directory identity -- locking out an organization admin who is not a mapped worker, and
limiting a mapped manager to their own subtree. See _resolve_forecast_effective_scope, which
asks resolve_scope for a directory whenever a leader_user_key is present so the organization
view still arrives with directory_generation_id set.
No custom interval (no caller-supplied bucket boundaries) and no real group_by
breakdown -- group_by accepts only "total" today, reserved for a future per-provider/
model forecast.