Fix MagazineManager evicting every other magazine on registration

[tshan10]

The bug

MagazineManager.refresh(List<Magazine<?>>) replaced the entire registry instead of upserting into it. A caller registering magazines one at a time — the natural reading of "refresh", and what the method did in 1.x — unregistered every other magazine. The next access to one of them threw MAGAZINE_NOT_FOUND, and rebuilding the handle cost a shard configuration read, because Magazine's constructor ends with an unconditional baseMagazineStorage.initialize(magazineIdentifier).

Nothing was deleted from storage — a Magazine is a handle. The cost is latency, and under concurrent single-magazine registrations the miss rate approaches 100%.

Why it regressed

1.x	magazines.forEach(m -> magazineMap.put(m.getMagazineIdentifier(), m)) — upsert
2.0.0	magazineMap.set(magazines.stream().collect(toUnmodifiableMap(...))) — replace

2.0.0 fixed a genuine thread-safety bug (unsynchronised HashMap under concurrent refresh/get) by publishing an immutable map through an AtomicReference. The semantic change came along with it, under an unchanged name and an unchanged javadoc.

Changes

Removed refresh(List<Magazine<?>>). This is source-breaking against 2.0.0, which is why it is called out here — but 2.0.0 has no adopters, and the name was the whole defect. Migration is a rename to replaceAll, with no behaviour change.

Added

Method	Purpose
register(Magazine<?>)	Add one magazine, leaving other registrations untouched
getOrRegister(String, Supplier<Magazine<T>>)	Return the registered handle, invoking the factory only on a miss
find(String)	Non-throwing lookup returning Optional
unregister(String)	Drop one registration; storage untouched
replaceAll(List<Magazine<?>>)	The replace-everything operation, named accordingly

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
82.3% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud