Add sort-by-Release-Plan-ID option to Release Plan Dashboard

[Copilot]

The Release Plans tab only sorted by SDK Release Month. Users need to sort by Release Plan ID (descending) to quickly spot newly incoming releases.

Changes

• Alpine store: Added sort: 'month' to filters (default unchanged)
• UI: Added a <select> dropdown in the tab bar, visible only on the Release Plans tab, with options for "SDK Release Month" and "Release Plan ID"
• Render logic: Introduced sortByReleasePlanId comparator (descending) and a sortFn selector that replaces hardcoded sortByReleaseMonth calls in splitByState
• Reactivity: Registered store().filters.sort in the Alpine effect so sort changes trigger re-render
• CSS: Added .global-sort-order to existing filter dropdown style rule

[Copilot]

Pull request overview

This PR updates the Release Plan Dashboard UI/render pipeline to support sorting the Release Plans view either by SDK Release Month (existing behavior) or by Release Plan ID (new), enabling users to more easily spot newly added plans.

Changes:

• Added a new filters.sort value in the Alpine store (defaulting to "month").
• Added a Release Plans–only sort <select> in the tab bar and corresponding styling.
• Updated render logic to select a sort comparator (month vs id) and wired sort changes into the Alpine reactive effect to trigger re-renders.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.

File	Description
tools/release-plan-dashboard/public/style.css	Extends existing global filter dropdown styling to the new sort dropdown.
tools/release-plan-dashboard/public/index.html	Adds filters.sort default and a Release Plans–only sort dropdown in the tab bar.
tools/release-plan-dashboard/public/app.js	Introduces sort selection logic and registers sort as a reactive dependency for re-rendering.

[maorleger]

hm I don't think this is quite what we want assuming two things:

1. releasePlanId is a string
2. we want descending order (largest IDs first)

If (1) is true, any non-numeric strings will cause it to silently fail sorting (because they will end up as NaN). This may be fine if we truly expect IDs to be a stringified number but might as well be safe and avoid implicit casts

If (2) is true, then I think we need to flip a and b here (b - a) instead of (a - b)

I sketched out this playground to show what I mean which is hopefully helpful to clarify