ENH: restore concrete generic Parachute class

[Gui-FernandesBR]

Summary

Addresses @MateusStano's pre-release review comments on #1048 (the HemisphericalParachute design concern, the noise parameter, and the drag_coefficient docstring), before the v1.13.0 tag is published.

The #958 refactor effectively renamed the concrete Parachute into HemisphericalParachute and left the old name as an abstract base — the hemispherical added-mass physics has been Parachute's behavior since at least v1.11 (the old hard-coded R = 1.5). That made Parachute(...) un-instantiable (a breaking change) without adding modeling capability, since there is only one concrete geometry.

Changes

• Parachute is concrete again, with its exact v1.12.1 signature and physics (u_dot, added mass, serialization move back into it). User code from v1.12.x runs unchanged, warning-free, with identical results. parachute_type is now a class attribute ("generic").
• HemisphericalParachute becomes a thin subclass: it makes the canopy geometry explicit, keeps the door open for future geometry-specific models (parafoil, flat circular, ...), and does not expose the noise parameter — noisy trigger readings should come from the Sensors infrastructure instead. Its drag_coefficient docs no longer suggest flat-circular/extended-skirt values (those stay on the generic class, where they make sense).
• Legacy Rocket.add_parachute(name, cd_s, ...) builds a generic Parachute again, keeping the FutureWarning nudge towards the object-passing API.
• Serialization: legacy .rpy signatures (rocketpy.rocket.parachute.Parachute) remap to the generic class at its new module path; round-trips preserve the concrete class.
• Docs: user guides and example notebooks return to the generic Parachute (several pass noise, which the subclass no longer accepts — including hedy_flight_sim.ipynb, which was never migrated and would break as released). The v1.13.0 changelog no longer lists a breaking change for parachutes.

Verification

• Full unit suite: 1690 passed, 13 skipped.
• Parachute-related flight integration tests: 4 passed.
• End-to-end smoke: generic Parachute with historical signature reproduces the v1.12 radius/added-mass values; legacy kwargs path emits exactly one FutureWarning and returns a Parachute; legacy .rpy decode reconstructs a generic Parachute with the noise field preserved.

Release note

This PR should be merged to develop and flow to master through #1060 before tagging v1.13.0, so the release ships without the parachute breaking change.

🤖 Generated with Claude Code

[codecov]

Codecov Report

❌ Patch coverage is 96.77419% with 2 lines in your changes missing coverage. Please review.
✅ Project coverage is 81.83%. Comparing base (f464601) to head (3e84998).

Files with missing lines	Patch %	Lines
rocketpy/rocket/parachutes/parachute.py	96.49%	2 Missing ⚠️

Additional details and impacted files

@@             Coverage Diff             @@
##           develop    #1061      +/-   ##
===========================================
- Coverage    81.84%   81.83%   -0.02%     
===========================================
  Files          118      118              
  Lines        15254    15241      -13     
===========================================
- Hits         12485    12472      -13     
  Misses        2769     2769              

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[MateusStano]

The more I look at this implementation the more I think we need to revert it

It is essentially a breaking change right now, and it is adding nothing new

The worst part is that I don´t see this being the way to scale the parachute models as well. By adding this we are definitely going to need another breaking change (or add more big deprecation warnings)

Also, we are aiming for implementing parafoils and we will need a more robust architecture, that will definitely collide with what we have here.

Just skecthing quickly with claude, and something like this is a much better implementation:

rocketpy/rocket/parachutes/
├── parachute.py # Parachute: the container that composes everything
├── deployment.py # Deployment: trigger + inflation dynamics
├── geometry.py # CanopyGeometry / added-mass models (shape of the parachute)
├── dynamics.py # DescentDynamics strategies ("how it flies") (Parafoil control dynamics would act here)
├── presets.py # what the user would touch: HemisphericalParachute, Parafoil, ... (maybe have a bunch of files for this instead of presets.py)
└── init.py

Lets just revert this one

[Gui-FernandesBR]

@MateusStano , I understand your concern and overall it makes a lot of sense. The new HemisphericalParachute class thought like a good idea at the begging, but now... I see what your pointing at.

The problem, however, is that we still have a lot to process and reflect yet before making any architecture move here.
For instance, I don't instantly agree with the addition of parafoils as a specific kind of Parachute. IMO those are two complete different things.

My suggestion is for use to revert the changes made to the Parachute class and then release v1.13.0 without changing Parachute-related feature. If you agree we can move forward to a next PR and close this

[MateusStano]

My suggestion is for use to revert the changes made to the Parachute class and then release v1.13.0 without changing Parachute-related feature. If you agree we can move forward to a next PR and close this

Im reverting it right now