chore: make analytics package public exports explicit (remove star-import leak)

[NoopDog]

Follow-up from the review of #4926 (part of the #4913 retirement effort), deferred there as out of scope.

Problem

report_elements.py star-imports the underscore-private _report_utils (which has no __all__), and also does from .entities import *. Without __all__, every module-level name — including imported ones — is re-exported, so private helpers and module aliases become de-facto public API of report_elements. After #4926 this surface includes get_data_df, get_df_over_time, strings_to_lists, and the ga / np / pd / dt module aliases.

Why it matters

• Renames inside the nominally private _report_utils can silently break consumers bound via report_elements.*.
• The trap in the other direction: static_site/fetch.py:401 uses elements.ADDITIONAL_DATA_BEHAVIOR, which resolves only via star-import re-export (fetch.py's explicit from ..entities import (...) block does not include it). A naive cleanup replacing the star imports with explicit imports breaks static-site generation with AttributeError — and only on runs that pass historic_data_path (i.e. the monthly job), so a smoke test won't catch it.

Suggested fix

1. Replace the star imports in report_elements.py with explicit imports of the names it actually re-exports (or add __all__ to _report_utils.py and entities.py).
2. Make fetch.py import ADDITIONAL_DATA_BEHAVIOR explicitly from ..entities.
3. Verify with a fresh-venv generate_static_site.py run including historic_data_path, per the chore: retire legacy analytics formats — tracking #4913 verification convention.

Context: #4926 (review)