Proposal: Official `Temporal`/`Intl` time adapter, as a path to no external date library requirement

## Feature Proposal

Chart.js’ [time scale docs](https://www.chartjs.org/docs/latest/axes/cartesian/time.html#date-adapters) currently state:

> “The time scale requires both a date library and a corresponding adapter to be present.”

With the JavaScript [Temporal API](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Temporal) and [Intl.DateTimeFormat](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/DateTimeFormat), the platform now provides the primitives needed for time parsing, calendar math, time-zone handling, and label formatting. This proposal suggests:

1. An official `chartjs-adapter-temporal` package that relies only on `Temporal` + `Intl` (no third-party date library).
2. A future core enhancement to automatically use this adapter when `globalThis.Temporal` is available, enabling the docs to eventually drop the “date library” requirement.

---

## Context

Temporal is a [Stage 3 TC39 proposal](https://github.com/tc39/proposal-temporal), and is already being used in production via polyfills:

Polyfill | Repo | Status
-- | -- | --
[@js-temporal/polyfill](https://www.npmjs.com/package/@js-temporal/polyfill) | [js-temporal/temporal-polyfill](https://github.com/js-temporal/temporal-polyfill) | Alpha release available
[temporal-polyfill](https://www.npmjs.com/package/temporal-polyfill) | [fullcalendar/temporal-polyfill](https://github.com/fullcalendar/temporal-polyfill) | Beta release available

It would be nice for the projects that have left the "old world" javascript date handling (via these polyfills) to not need to pull in date libraries "just" for chart.js.

---

## Migration / compatibility

- This new adapter would be **opt-in** as `chartjs-adapter-temporal` and would work with the current `time` scale.
- Existing adapters (moment, dayjs, luxon, etc.) and docs remain unchanged initially.
- **Future (non-breaking) enhancement:**
If `globalThis.Temporal` exists at runtime, Chart.js core could automatically use the Temporal adapter. Otherwise, behavior stays exactly as it is today.

At that point, the docs could evolve to something like:

> “If Temporal is available, no additional date library is required. Otherwise, install one of the existing adapters.”

This provides a path to eventually remove the blanket requirement that “the time scale requires both a date library and a corresponding adapter.”

---

## Considerations

- `formats()` (and `time.displayFormats`) would return `Intl.DateTimeFormatOptions` objects in this adapter, while other adapters continue to return string tokens
- Quarter / ISO-week labels are not directly built into `Intl`. Is a small amount of custom logic in the adapter (similar to how current adapters already special-case these) acceptable?

### Possible Implementation

The adapter would implement the existing Chart.js date adapter surface using only platform APIs:

- **`parse(value)`**
Normalize input to `Temporal.Instant` / `Temporal.ZonedDateTime` and return epoch milliseconds.

- **`add` / `diff` / `startOf` / `endOf`**
Use `Temporal.ZonedDateTime` for calendar-aware and time-zone-aware math (including DST boundaries and month/quarter/year boundaries).

- **`format`**
Use `Intl.DateTimeFormat` to produce tick/tooltip labels.

- **`formats()`**
Return `Intl.DateTimeFormatOptions` objects (for each time unit) instead of moment-style format strings.

Time zone would be explicit via `Temporal.ZonedDateTime`, rather than implicit in the host environment.