widenTargets

jar -> the entry names the overlay carries for it, in classpath order, NOT deduplicated — see dedupeEntries for why that is the caller's call. Jars contributing nothing are absent. A jar that fails to open contributes nothing, is logged, and lands in failed, which holds back the stamp of whichever shard was carrying it so the next launch retries that one alone.

Membership is decided by NAME, before a class byte is read — that is what keeps the build one streaming pass. So every shouldWiden class is carried, widened or original bytes alike. Filtering by OUTCOME instead ("drop what widening did not change") is not a per-class call: an unchanged nested member left behind splits its nest group across two classpath units, and the K2 library session rejects that. Doing it right needs group-aware buffering, and what that would save — unchanged AND without nest siblings — is a small enough slice of the overlay to leave on the table.

renameFor drops the classes it renames: nothing in a renamed overlay refers to them under those names, so carrying a second view of the same 7k classes is dead weight. They stay resolvable behind the overlay for source that spells one out. Per-jar, because a jar already IN the target namespace is not renamed at all — its names are not the ones that move, however much the table's keys look like them.