Timeline plugin: time mode control

[sandesh-sp]

Replaces the time mode placeholder with the granularity switcher: one button per mode in canonical order, active mode highlighted. Missions choose which of YEAR, MONTH, DAY, HOUR appear and which one the timeline starts on.

Stack — merge in order, starting from the base:

1. Timeline plugin: shell and component placeholders #239 shell and component placeholders → development
2. Timeline plugin: timeline view #240 timeline view
3. Timeline plugin: date selector #241 date selector
4. Timeline plugin: playback controls #242 playback controls
5. Timeline plugin: time mode control #243 time mode control

[sandesh-sp]

Review pass over the stack (#239–#243). Pushed as 8694289, rebased on #239–#242.

In this PR

• The selected mode was carried only by a CSS class. No aria-pressed, no group role — a screen-reader user heard "YEAR button, MONTH button, DAY button, HOUR button" with no indication of which granularity was applied or that they form one mutually exclusive set. Now a labelled role="group" with aria-pressed per button. The same plugin already does this correctly two files over in DateSelector/DayCalendar, so it was an internal inconsistency rather than house style.
• Inactive labels sat at ~2.24:1. --theme-color-base-light (#a9aeb1) on the control's white background at 10px/800 — nowhere near the large-text exemption, so AA wants 4.5:1. Moved to --theme-color-base-darker, with hover going to the primary colour rather than repeating the same grade.

One correction to the review that produced this: it flagged the same low-contrast pattern at three other lines and asked for all four to be fixed. Checking each, only this one is a real failure — two are :disabled states, which WCAG 1.4.3 exempts, and the fourth is the info tooltip's body text, which is light-on-dark and passes comfortably. Left those alone.

Depends on #239

The shownTimeModes / defaultTimeMode plumbing this PR completes was inert before the base PR's fix: tool:getVars was requested at mount, but core registers that handler in L_.fina() after all layers load and request throws for an unregistered name, so every mode setting was swallowed into a console.warn and never applied. With the readiness guard in #239 the config now actually reaches this control.

I traced the normalization itself and it's sound — an empty or all-invalid shownTimeModes falls back to the full order, effectiveModes[0] can't be undefined, and a defaultTimeMode outside the shown set correctly clamps to the first shown mode. The checkbox/multiselect/dropdown types all exist in Maker.js and the shapes the Configure page persists match what the adapter parses.

tsc --noEmit clean, 898 unit tests pass.