Validate AfosId/WmoIdentifier character classes before IEM SPS URLs

[MikeWills]

Summary

Fixes the one real finding (Low severity) from the earlier full codebase security review.

• MapService.BuildIemSpsUrl/VerifyIemSpsAsync only length-checked alert.AfosId/alert.WmoIdentifier before embedding substrings of them into a colon-delimited IEM autoplot #217 URL (pid:{pid}::segnum:0::...).
• Contrast with the sibling BuildIemUrl/ResolveIemPhenomenaAsync: their VTEC-derived inputs are already constrained to safe character classes ([A-Z]{4}/[A-Z]{2}/[A-Z]/\d{4}) by NwsAlertService.VtecPattern's regex before ever reaching MapService. AfosId/WmoIdentifier had no equivalent validation.
• Added AfosSpsPattern (^SPS[A-Z]{3}$) and Wmo6Pattern (^[A-Z0-9]{6}$), checked before building the URL. On failure, falls back to Mapbox — identical to the existing length-check failure path, no new failure mode.
• Also wrapped the wfo query parameter in VerifyIemSpsAsync's GET request with Uri.EscapeDataString as further defense in depth.
• Verified the regexes against real example values (SPSMPX, SPSOUN, WWUS83) and injection-shaped strings (colons, slashes, wrong length/case) in an isolated test before landing — all matched/rejected as expected.
• Added a CLAUDE.md Common Pitfalls entry documenting the "validate character classes, not just length, for untrusted fields in IEM's colon-delimited URLs" convention for future contributors.

Risk: since real NWS AfosId/WmoIdentifier values already conform to these patterns, this should be a no-op for all legitimate SPS alerts — exploitability of the original gap was already low (NWS's own trusted feed), this is defense in depth.

Test plan

• dotnet build passes (done, 0 warnings/errors)
• Confirm a real SPS alert still gets its IEM autoplot #217 map image (not a Mapbox fallback) after this change