v3 converter potentially generates unnecessary prefixes

[tpwalke2]

Version3Converter fabricates a prefix for every migrated V2 entry, even non-matching sides
src/main/java/com/tpwalke2/bluemapsignmarkers/core/signs/persistence/loaders/Version3Converter.java:26

var markerGroup = Arrays.stream(markerGroups).filter(m -> m.type() == MarkerGroupType.POI).findFirst().orElseThrow();

Verified by reading SignLinesParseResultV2 (markerType is @Nullable, no prefix field at all) and
VersionedFileSignEntryLoader.java:31-33, which calls Version3Converter.convertToV3 unconditionally for every
entry's front and back text, regardless of whether markerType was null (meaning that side never matched any
group in the original V1/V2 data). Every migrated sign — including sides that originally matched nothing — gets
assigned the prefix of whichever POI-type MarkerGroup happens to be first in the current config array. Two
distinct bugs stack here: (a) blank/non-matching sides spuriously become "matching" after migration, fabricating
markers that never should have existed, and (b) if more than one POI-type group is configured, every migrated sign
silently gets reassigned to the first one regardless of which prefix it actually had. .orElseThrow() also throws
an uncaught NoSuchElementException if the config has zero POI-type groups (e.g. "markerGroups": []), which
propagates uncaught through the fallback path all the way to SignProvider's outer catch — total loss of all
persisted signs for the session. (b) alone is already flagged as a known limitation in agent-context/context/ config-and-persistence.md; (a) is a separate, unacknowledged defect found during this review.