Bug: 1:m relationship between route_id and recent_combined_name

[amandaha8]

Where did the bug occur?
Select from the below, and be sure to affix the appropriate label to this issue (e.g. dataset, jupyterhub, metabase, analysis.calitp.org)

• Data (the warehouse)
• JupyterHub
• Metabase
• analysis.calitp.org
• Other (add detail)

Describe the bug

• There are 200+ instances in which one recent_combined_name value maps to multiple route_id values.
• Figure out why this is happening - it could be these operator have different versions of the same route or an operator (like LA Metro) actively chooses new route_id values each time when publishing data for the same recent_combined_name value.
• Aggregate the dataframe up to recent_combined_name, service_date, and portfolio_organization_name. This will require some finesse for metrics like avg_scheduled_minutes and speed_mph because I'm unsure what's the correct way to represent these values.

To Reproduce
Steps to reproduce the behavior:

1. Dataframe f"{RT_SCHED_GCS}{DIGEST_RT_SCHED}.parquet" at the end of gtfs_digest/merge_data.py

unique_route_ids = (
    df.groupby([ "portfolio_organization_name", "recent_combined_name"])
    .agg({"route_id": "nunique"})
    .reset_index()
)

3. unique_route_ids2 = unique_route_ids.loc[unique_route_ids.route_id > 1]
4. See which recent_combined_name values have more than one route_id.

Expected behavior
It's OK for recent_combined_name values to have more than one route_id but this needs to be grouped before data makes it into the Operator Grain of GTFS Digest or else the charts will disjointed.

Additional context

• Build off the work Tiffany did Research Request - Route identification over time #924 and this PR.

[tiffanychu90]

It's ok for recent_combined_name to group multiple route_ids only when route_short_name and route_long_name are the same, see the LA Metro route_id example.

It is not ok to group them when route_short_name and route_long_name are different, and the time_series_utils operators that get extra parsing only had that to handle cases like:

	route_id	short_name	long_name	combined_name	desired_combined_name
VCTC (Mar 2023 - Jun 2024)	4134	80	80-Coastal Express	80_80-Coastal Express	80-Coastal Express (this is why time_series_utils is there, it's not pretty this way, and some operators consistently repeat short/long name info, so grabbing just the long_name is enough)
VCTC (Sep 2024-current)	4134	80	80-89 Coastal Express	80-89 Coastal Express (parsing away short_name would be incorrect now)	80_80-89 Coastal Express
VCTC (Mar 2023 - Jun 2024)	4146	87	87 Coastal Express	87__87-Coastal Express (parsing away short_name is correct)	87-Coastal Express (time_series_utils is parsing away short_name)
VCTC (post Sep 2025)	4146	87	80-89 Coastal Express	80-89 Coastal Express (parsing away short_name would be incorrect now)	87__80-89-Coastal Express
LA Metro	2-13167		Metro Local Line	2__Metro Local Line (same route, though different route_id)	2__Metro Local Line
LA Metro	2-13168	2	Metro Local Line	2__Metro Local Line (same route, though different route_id)	2__Metro Local Line

[tiffanychu90]

By simply removing VCTC (and whichever operator has this), you should get the recent_combined_name values you want (which is the default rule: route_short_name__route_long_name). For VCTC, their most recent service date is the one that is used anyway, so all the past 80__80 Coastal Express wouldn't show up anymore.