Batch initial connectedCallback renders into a single microtask flush

[Copilot]

For N <relative-time> elements inserted together, connectedCallback was calling update() synchronously per element — N ancestor-walking locale/timeZone/hourCycle resolutions, N Intl format passes, N shadow-DOM writes — all blocking layout at startup.

Changes

src/relative-time-element.ts

• New batch infrastructure: module-level pendingElements: Set<RelativeTimeElement> and async flushPending() that snapshots + clears the set before iterating (safe against mid-flush connect/disconnect side-effects), then calls update() on each element after a single await Promise.resolve().
• connectedCallback: enqueues into the batch instead of calling update() synchronously. If #updating is already set (an attributeChangedCallback microtask is already in-flight for this element), skips enqueuing — that microtask handles the first render.
• disconnectedCallback: adds pendingElements.delete(this) so elements removed before the flush are never updated.
• attributeChangedCallback: short-circuits with return if pendingElements.has(this) — defers to the pending batch flush rather than scheduling a redundant second microtask.

// Before
connectedCallback(): void {
  this.update()  // synchronous — blocks for every element at insert time
}

// After
connectedCallback(): void {
  if (this.#updating) return  // attributeChangedCallback already scheduled a microtask
  pendingElements.add(this)
  if (!pendingFlush) {
    pendingFlush = true
    flushPending()  // one microtask for the whole batch
  }
}

The microtask resolves before paint, so rendered text, title, dispatched events, and the accessibility tree are identical to the previous synchronous behavior.

test/relative-time.js

Four new tests in a connectedCallback microtask batching suite: single-element deferred render, multi-element batch, disconnect-before-flush safety, and attribute-change-after-connect coalescing.