Description

This PR adds feature importance logging using feature_importances_, which Random Forest models expose for free after .fit().

• random_forest.py: after training, retrieve feature_importances_, map to column names, sort descending, and log
• test_rf_models.py: add TestFeatureImportanceLogging to verify the importance block appears in logs

Example Log:

active_days_ratio: 0.1275
std_days_between: 0.1253
days_seen_count: 0.1157
login_attempts_per_day: 0.1133
days_since_first_seen: 0.1111
days_since_last_seen: 0.1009
login_attempts: 0.0993
interaction_count: 0.0794

Related issues

closes: #1050

Type of change

• Bug fix (non-breaking change which fixes an issue).
• New feature (non-breaking change which adds functionality).
• Breaking change (fix or feature that would cause existing functionality to not work as expected).
• Chore (refactoring, dependency updates, CI/CD changes, code cleanup, docs-only changes).

Checklist

Please complete this checklist carefully. It helps guide your contribution and lets maintainers verify that all requirements are met.

Formalities

• I have read and understood the rules about how to Contribute to this project.
• I chose an appropriate title for the pull request in the form: <feature name>. Closes #999
• My branch is based on develop.
• The pull request is for the branch develop.
• I have reviewed and verified any LLM-generated code included in this PR.

Docs and tests

• I documented my code changes with docstrings and/or comments.
• I have checked if my changes affect user-facing behavior that is described in the docs. If so, I also created a pull request in the docs repository.
• Linter (Ruff) gave 0 errors. If you have correctly installed pre-commit, it does these checks and adjustments on your behalf.
• I have added tests for the feature/bug I solved.
• All the tests gave 0 errors.

GUI changes

Ignore this section if you did not make any changes to the GUI.

• I have provided a screenshot of the result in the PR.
• I have created new frontend tests for the new component or updated existing ones.

Review process

• We encourage you to create a draft PR first, even when your changes are incomplete. This way you refine your code while we can track your progress and actively review and help.
• If you think your draft PR is ready to be reviewed by the maintainers, click the corresponding button. Your draft PR will become a real PR.
• If your changes decrease the overall tests coverage (you will know after the Codecov CI job is done), you should add the required tests to fix the problem.
• Every time you make changes to the PR and you think the work is done, you should explicitly ask for a review. After receiving a "change request", address the feedback and click "request re-review" next to the reviewer's profile picture at the top right.