[Feature request]: Make active-route blockage parameters configurable

Before proceeding, is there an existing issue or discussion for this?

• I have done a search for similar issues and discussions.

Description

PR #36 adds active-route blockage detection to the plan executor. The current implementation uses three hard-coded constants:

• BLOCKAGE_DEBOUNCE = 300 ms: how long a route must remain blocked before reporting CODE_PATH_BLOCKED
• REPLAN_COOLDOWN = 2 s: minimum delay between blockage reports
• OCCUPIED_THRESHOLD = 50: occupancy-grid value above which a cell is treated as blocked

These defaults work for the current demos but have not been tuned across different robots, map update rates, or deployments.

Implementation Considerations

Expose the values as ROS parameters while preserving the current defaults.

The implementation should:

• Reject negative debounce and cooldown durations
• Restrict the occupancy threshold to valid occupancy-grid values
• Document how each parameter affects replanning
• Test the default values and parameter overrides

We should also consider whether the parameters belong to the plan executor globally or need per-robot overrides.

Alternatives

Keep the values hard-coded. This is simpler, but tuning them would require rebuilding the plan executor and would make deployment-specific configuration difficult.

Additional information

This follows review feedback on #36 requesting a ticket to document and track these constants.

Start with the active-route blockage detection added by PR #36 and locate the plan executor's three hard-coded constants: BLOCKAGE_DEBOUNCE, REPLAN_COOLDOWN, and OCCUPIED_THRESHOLD. Check how the plan executor currently reports CODE_PATH_BLOCKED, then review the project's parameter and test conventions. Done means configurable parameters preserve current defaults, reject invalid values, document replanning effects, and cover defaults and overrides in tests.