🔀 Feature/format figure

[mvillasante]

This PR refactors the population trend rendering pipeline, adds a new CLI command render-population-trend, and introduces legend visibility control. 🚧

Changes

Added

• New CLI command render-population-trend (replaces the now-deprecated plot-population-trend)
• --show-legend / --no-show-legend option to render-population-trend to control legend visibility
• show_legend parameter and hide_legend() method to Plotter_Population_Trend_Model
• Test class Tests_Plotter_Population_Trend_Model_without_legend for legend hiding behavior
• Test tests_no_hide_legend confirming legend persists when show_legend=True

Changed

• _render_population_trend refactored: accepts pd.DataFrame and dict instead of file path strings; returns the Graficador object instead of saving the figure internally. File I/O responsibility moved to the CLI command functions.
• plot_population_trend (deprecated): now emits a deprecation warning via both typer.secho and warnings.warn, then delegates to the same internal logic.
• Added self.ax.legend() call in Plotter_Population_Trend_Model.__init__ to ensure the legend artist exists before hide_legend() can manipulate it.
• Added ${m} variable to the green TDD commit message in the Makefile for commit message customization.
• Updated test_render_population_trend_new_command_works to pass --no-show-legend.

Deprecated

• plot-population-trend CLI command is deprecated in favor of render-population-trend. Will be removed in v6.0.0.

Notes

• The existing plot_population_trend_from_cpue command is not affected by these changes.
• Backward compatibility is preserved: the old plot-population-trend command still works (with deprecation warnings).

[mvillasante]

Checklist for Pull Request

• Small: The pull request has fewer than 100 lines.
• Passing: The CI pipeline is passing.
• Technical debt reduction: Did we reduce any form of technical debt? Are we confident that this change did not introduce or increase technical debt?

---

• Complexity: Could the code be made simpler? Would another developer be able to easily understand and use this code when they come across it in the future? Is this code adding functionality that isn't presently needed?
• Design: Is the code well-designed and appropriate for your system?
• Tests: Does the code have correct and well-designed automated tests? Does the code behave as the author likely intended?
• Interface: Any interface changes are sensible and look good. Is the way the code behaves good for its users?

---

• CHANGELOG.md: Are the changes recorded in this file following this standard?
• Versioning: Are version numbers updated according to semantic versioning guidelines (e.g., MAJOR.MINOR.PATCH)?
• Documentation: Did the developer also update relevant documentation? Does the exposed functions have docstrigns? No tenemos pero nos vamos a pasar de líneas.
• CITATION.cff: Is the citation files included and updated following the this standard? Aquí y aquí hay ejemplos.

---

• Naming: Did the developer choose clear names for variables, classes, methods, etc.? Did we replace unnecessary comments with clear variable names, well-named functions, and small cohesive blocks?
• Style: Does the code follow our style guides?

---

• YAGNI: The developer is not implementing things they might need in the future but don’t know they need now.
• Good Things: If you see something nice in the pull request, tell the developer, especially when they addressed one of your comments in a great way.

[MemoOlv]

👍🏾 LGTM