Follow-up from PR #408.\n\nThe settings UI currently groups transaction explorer endpoints by deriving a provider key from explorer IDs/names. That works for the current fixed set, but it is fragile if new explorers or local integrations are added with overlapping names.\n\nScope:\n- Replace string-substring grouping with an explicit provider key from config/API, or a deterministic mapping owned near the explorer definitions.\n- Keep public/local variants grouped under the same provider card.\n- Preserve existing translated platform labels and explorer logos.\n\nThis is not release-blocking for the current custom explorer/settings redesign; it is future-proofing before the explorer set grows.
Follow-up from PR #408.\n\nThe settings UI currently groups transaction explorer endpoints by deriving a provider key from explorer IDs/names. That works for the current fixed set, but it is fragile if new explorers or local integrations are added with overlapping names.\n\nScope:\n- Replace string-substring grouping with an explicit provider key from config/API, or a deterministic mapping owned near the explorer definitions.\n- Keep public/local variants grouped under the same provider card.\n- Preserve existing translated platform labels and explorer logos.\n\nThis is not release-blocking for the current custom explorer/settings redesign; it is future-proofing before the explorer set grows.