fix: include followRail in drawPatternFromStops to enable snap to rail and avoid thrown to else which always return straight line

[faisalanshory]

…l and avoid thrown to else which always return straight line

Checklist

• [X ] Appropriate branch selected (all PRs must first be merged to dev before they can be merged to master)
• [X ] Any modified or new methods or classes have helpful JSDoc and code is thoroughly commented
• The description lists all applicable issues this PR seeks to resolve
• The description lists any configuration setting(s) that differ from the default settings
• All tests and CI builds passing
• The description lists all relevant PRs included in this release (remove this if not merging to master)
• e2e tests are all passing (remove this if not merging to master)

Description

This PR fixes an issue in the trip pattern editor where the "Snap to Rail" functionality was being ignored when generating a pattern shape from stops.

The Issue: Previously, the logic in drawPatternFromStops only prioritized followStreets. When a user selected "Snap to Rail" (which sets followRail to true), the code would fall through to the else block, which unconditionally generates straight line segments. This made it impossible to auto-generate rail-snapped geometries even when the routing engine (like GraphHopper) supported it.

The Fix: I have updated the condition in drawPatternFromStops to include followRail. Now, if either followStreets or followRail is enabled, the application correctly calls the routing service (getPolyline) with the appropriate parameters. This ensures that rail patterns are correctly snapped to tracks instead of defaulting to straight lines.