Cleanup raptor on trip access

[t2gran]

Summary

This PR continues the Raptor API/SPI cleanup series (follows #7460). It refactors on-board trip access boarding to eliminate a dedicated second-pass through routes and improve encapsulation of trip-schedule lookup.

On-board trip access integration

• Removes the separate routeTransitUsingOnBoardTripAccess() method from DefaultRangeRaptorWorker and RangeRaptorWorker interface
• On-board arrivals are now indexed by route index and stop position via a new OnBoardTripAccessPathsForRoute helper, and consumed inline during the regular boardAndAlightPattern traversal
• Moves on-board trip arrival handling into McStopArrivals, keeping MC-specific logic contained

RaptorTripScheduleStopPosition DTO

• Replaces ad-hoc (tripSchedule, stopPosition) pairs in the access API with a proper DTO
• Adds test coverage for the DTO

RaptorTripScheduleReference SPI

• Introduces a new RaptorTripScheduleReference in the SPI, backed by RaptorTransitDataProvider, to look up a trip schedule by its index (THIS IS CURRENTLY UNUSED, BUT WILL BE USED IN A FOLLOW UP PR)
• This enables the on-board boarding integration to retrieve the trip from a stop index without passing through RaptorOnBoardAccess directly
• Adds test coverage

Naming cleanup

• tripIndex() → tripScheduleIndex() throughout (interface + all implementations)
• Renames boarding search methods for clarity; adds JavaDoc
• ArrivalsEventListenerMapper → McArrivalsEventListenerFactory
• Removes ModuleTestDebugLogging helper in favor of enabling debug logging uniformly across all module tests

Issue

🟥 No issue for this. This is part of migrating vi pass-through in Raptor to new "chained" routers. This will enable pass-through to be used with Transit Group Priority and later also enable heuristics for via.

Unit tests

✅ Unit tests updated/added

Documentation

✅ JavaDoc updated

Changelog

🟥 No functionality changed

Bumping the serialization version id

🟥 No serialized model classes changed

[codecov]

Codecov Report

❌ Patch coverage is 91.59664% with 10 lines in your changes missing coverage. Please review.
✅ Project coverage is 71.04%. Comparing base (41a3e99) to head (a0216a4).
⚠️ Report is 56 commits behind head on dev-2.x.

Files with missing lines	Patch %	Lines
...ptor/api/model/RaptorTripScheduleStopPosition.java	88.88%	1 Missing and 1 partial ⚠️
...lanner/raptor/spi/RaptorTripScheduleReference.java	90.00%	1 Missing and 1 partial ⚠️
...ansit/request/RaptorRoutingRequestTransitData.java	0.00%	1 Missing ⚠️
...dapter/transit/request/TripScheduleWithOffset.java	0.00%	1 Missing ⚠️
...r/raptor/rangeraptor/DefaultRangeRaptorWorker.java	96.00%	0 Missing and 1 partial ⚠️
...or/internalapi/OnBoardTripAccessPathsForRoute.java	90.90%	0 Missing and 1 partial ⚠️
...eraptor/multicriteria/arrivals/McStopArrivals.java	93.33%	0 Missing and 1 partial ⚠️
...r/multicriteria/arrivals/c1/AccessStopArrival.java	80.00%	0 Missing and 1 partial ⚠️

Additional details and impacted files

@@              Coverage Diff              @@
##             dev-2.x    #7485      +/-   ##
=============================================
+ Coverage      71.00%   71.04%   +0.03%     
- Complexity     20977    21023      +46     
=============================================
  Files           2345     2354       +9     
  Lines          87222    87299      +77     
  Branches        8637     8633       -4     
=============================================
+ Hits           61931    62019      +88     
+ Misses         22302    22295       -7     
+ Partials        2989     2985       -4     

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

🚀 New features to boost your workflow:

• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[t2gran]

Note! I missed a few places when changing from OnBoardAccess --> StartOnBoardAccess. I will fix this in the next PR - this is blocking both my(upcomming) and @sigtot PRs. So I prefer to address renaming and larger changes in the next PR.

[jessicaKoehnke]

I have found a few small things, otherwise very nice simplification!

[jessicaKoehnke]

should this be here when it only depends on the trip?

[t2gran]

Not sure I understand, can you explain?

[jessicaKoehnke]

nothing from the RaptorRoutingRequestTransitData class or instance is actually needed to do the work. Only the trip itself, that's why I question the location of the method. For example, might it make more sense to put it in the TripSchedule itself?

[jessicaKoehnke]

I will be on vacation next week, so I approve this for now so that you are not blocked. But I would like you to think of a good justification for where this method should be and maybe change it's location in one of your next PRs. (If there is a good reason for it being here, that might be fine, I would just like that choice to have been made consciously)

[sigtot]

Small docs suggestions otherwise looks good to me