aggregator(provider-display): underscore strip breaks one-shot iterables and collapses renamed+plain providers to one display name

Summary

The leading-underscore display strip added to providerDisplayNames in PR #6889 (commit 8dc7e75af7, the #1823 provider rename) introduced two defects in pm-stack/aggregator/src/provider-display.ts:

1. The function now spreads its Iterable<string> parameter twice, so a one-shot iterable produces a garbage map. providerDisplayNames is declared over Iterable<string> (line 37), and the pre-rename implementation spread it exactly once. The new code spreads it at line 38 to build the stripped list and again at line 44 (const originals = [...names]) to recover the keys. For a one-shot iterable — a generator, a Map.keys() / Set.values() iterator — the second spread is empty, originals[i] is undefined, and the result is a single-entry map keyed by undefined. Every lookup misses, and providerDisplayName silently falls back to the unstripped canonical id.
2. The underscore strip is not collision-aware, unlike the -direct rule in the same function. The -direct strip keeps the suffix when a plain base provider exists in the same set, expressly "so the two stay distinguishable" (module header). The underscore strip has no such guard: a set containing both the renamed id and its plain base — e.g. _claude and claude, or the new pool series _commandcode and the pre-rename series commandcode that the rename deliberately kept in the store — renders both providers under the identical display string.

Evidence

pm-stack/aggregator/src/provider-display.ts:37-58 at 4cd2927643 (origin/main):

export function providerDisplayNames(names: Iterable<string>): Map<string, string> {
  const list = [...names].map((name) => { ... });   // first spread (line 38)
  ...
  const originals = [...names];                      // second spread (line 44)

Verified this run on the laptop with the real file verbatim (md5 f16c0bdb00963613ca7b19399f667520, probe ~/git/fleet/probe-provider-display, bun 1.4.4):

Control: the shipped suite pm-stack/aggregator/test/provider-display.test.ts passes 11/11 on the same tree (run via git archive origin/main) — it only ever passes arrays, and has no renamed+plain pair case.

All current call sites (render.ts:2167, render.ts:3364, render.ts:3714) pass arrays, so defect 1 is latent today — but the exported signature promises Iterable<string>, and the singular helper providerDisplayName(name, names) invites exactly the iterator inputs that break.

Why it matters

This module is the dashboard's one display-name rule, and its header states the contract: display strings change, ids/keys never do, and names that would collide stay distinguishable. Defect 1 breaks the type contract silently (no throw — wrong markup), and defect 2 makes two different providers/series indistinguishable on the quota board precisely in the migration window the rename created, where old and new ids coexist in the store by design.

Acceptance criteria

• providerDisplayNames reads its input exactly once: a generator or Map.keys() iterator yields the same map as the equivalent array, keyed by the exact input strings.
• When stripping the leading underscore would make a name's display equal to another distinct input's display in the same set (renamed + plain base both present, plain or dotted), the renamed name keeps a distinguishable display (mirroring the -direct rule's keep-on-collision behaviour); when there is no collision, the underscore is stripped as today.
• New regression tests in pm-stack/aggregator/test/provider-display.test.ts cover: a one-shot iterable input, and a renamed+plain pair (_claude + claude and/or _commandcode + commandcode).
• bun test test/provider-display.test.ts passes (existing 11 tests unchanged in behaviour).

Related: #1823 / PR #6889 (the rename that introduced the strip); #6125 (the original -direct display rule).