Remote write 2.0 (part 1/2): move start timestamp, keep writing legacy field for rolling upgrade

[krajorama]

What this does

This is part 1 of 2 for a phased rollout of the Remote Write 2.0 start-timestamp change across the distributed Mimir system (see #16471 for part 2, which will land only once this has fully rolled out).

Prometheus's Remote Write 2.0 spec moved the per-series created_timestamp field to a per-sample/per-histogram start_timestamp field (Sample field 3, Histogram field 17), reserving TimeSeries field 6.

1. Move start timestamp from TimeSeries to Sample/Histogram — adopts the new schema: moves the field, reserves the old one, and adapts every internal consumer (ingester, block-builder, mimirpb helpers). Since each sample/histogram now carries its own start timestamp, ingestion evaluates each one's start timestamp independently (deduplicating consecutive entries sharing the same value) instead of only ever acting on the first one in a batch. The OTLP appender keeps splitting a series into a new wire TimeSeries entry whenever the start timestamp changes (unlike part 2), so each entry it produces has exactly one start timestamp to report on the legacy field below.
2. Restore compatibility with legacy created_timestamp senders — decodes the reserved field 6 when present on the wire (without resurrecting it as a public Go field) and fans it out to every Sample/Histogram in that series that doesn't already carry its own StartTimestamp. This covers both external Remote Write 2.0 senders using the pre-final shape, and internal distributor→ingester gRPC / ingest-storage Kafka records from a not-yet-upgraded component.
3. Marshal the legacy field for not-yet-upgraded readers — the most important part of this PR: TimeSeries/TimeSeriesRW2 marshalling now also writes the reserved per-series field 6, derived from the first sample's StartTimestamp, or the first histogram's if there are no samples. This lets not-yet-upgraded readers (old ingesters, old internal tooling) keep working correctly throughout the rollout, since they only understand the old per-series field. This is a no-op for upgraded readers, since Unmarshal only fans the legacy value into a sample/histogram that doesn't already have its own StartTimestamp.

Rollout plan

• This PR (part 1) can be deployed safely to any subset of the fleet in any order: old and new binaries remain interoperable, since every write carries both the modern per-sample fields and the legacy per-series fallback.
• Once the whole fleet (and, for the ingest-storage architecture, Kafka retention) has rolled forward past this change, part 2 removes the legacy marshalling and the OTLP appender's start-timestamp-based series splitting, since they're no longer needed.

Test plan

• Unit tests updated/added across pkg/mimirpb, pkg/ingester, pkg/blockbuilder, pkg/distributor (including otlpappender), and pkg/continuoustest
• New tests in pkg/mimirpb/compat_rw2_test.go: Sample/Histogram.StartTimestamp round-trips over RW1 and RW2, legacy per-series created_timestamp fan-out (both the RW2-specific and the plain internal decode path), and TestMarshalLegacyCreatedTimestamp verifying the new marshal-side legacy field is written correctly (and is a no-op on round-trip through an upgraded reader)
• New integration test TestDistributor_RW2_StartTimestamp: pushes two samples with distinct start timestamps in one request and asserts each independently triggers its own zero sample
• make check-protos-equivalent regeneration verified idempotent
• go build ./... and broad go test sweep pass (aside from known pre-existing/environmental flakes unrelated to this change)

[krajorama]

note to reviewers: this is needed temporarily because the PreallocTimeseries no longer has space for it. We could reintroduce a private field in PreallocTimeseries, but this way only otlp is impacted which is less surface than all remote write.