[FIX][DOCS] #315 date feature compatibility and explicit docs

[W057]

Summary

• Document supported built-in string date_features in docs/core.html.md.
• Expand MLForecast constructor docstring with explicit supported options and compatibility guidance.
• Improve date-feature resolution across pandas/polars aliases (e.g. day_of_year, day_of_week, weekofyear) and calendar-boundary features.
• Raise clear ValueError listing supported features when an unknown string is used.
• Add tests for invalid feature errors and backend alias support.

Why

Makes supported features explicit and reduces backend/version-specific surprises for date feature extraction.

Tests

• /home/welink/dev/work/Nixtla/mlforecast/.venv/bin/pytest --no-cov tests/test_core.py -k "invalid_date_feature or date_feature_aliases_supported" -vv

Closes #315

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: caeec27de9

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Normalize polars dayofweek aliases to pandas semantics

In _compute_date_feature, mapping dayofweek/day_of_week directly to Polars weekday changes the feature meaning for Polars users: weekday follows ISO numbering (Mon=1..Sun=7), while pandas dayofweek/day_of_week is Mon=0..Sun=6. This silently shifts values when users switch engines or rely on pandas-compatible ranges, which can alter trained models and forecasts; these aliases should be normalized to pandas semantics (or not aliased).

Useful? React with 👍 / 👎.