Fix get_nexrad_location mutating shared NEXRAD_LOCATIONS table

[Yuxiang-Ren-HUB]

Problem

get_nexrad_location() converts the station's elevation from feet to
meters by writing the result back into the dict it just read from:

loc = NEXRAD_LOCATIONS[station.upper()]
loc["elev"] = loc["elev"] * 0.3048
return loc["lat"], loc["lon"], loc["elev"]

loc is not a copy -- it's a reference into the shared, module-level
NEXRAD_LOCATIONS dict, so the conversion is applied permanently.
Calling get_nexrad_location() a second time for the same station
applies the conversion again, silently corrupting the result:

>>> get_nexrad_location("KTLX")[2]
369.7224          # 1213 * 0.3048, correct
>>> get_nexrad_location("KTLX")[2]
112.69138752      # converted twice, wrong

Any code path that calls this function more than once for the same
station -- e.g. processing multiple files/sweeps from the same radar
in one process -- silently gets a wrong altitude after the first call.

Fix

Store the converted elevation in a local variable and return that,
instead of writing back into the shared table. NEXRAD_LOCATIONS is
now never mutated by this function.

Testing

Added tests/io/test_nexrad_common.py (previously no dedicated test
file existed for this module):

• test_get_nexrad_location_known_station: sanity-checks the returned
  lat/lon/elev for a known station.
• test_get_nexrad_location_repeated_calls_are_stable: regression test
  for this bug -- calls the function 3 times for the same station and
  asserts the elevation doesn't change, and that the underlying table
  entry stays at its original (feet) value.

Both pass locally.

[Yuxiang-Ren-HUB]

Friendly ping on this one — it looks like no CI has run yet. I believe workflows need a maintainer to approve them for a first-time contributor.
Happy to rebase or adjust anything if that would help. Thanks!

[scollis]

Hey! Patience please! We are updating our contributors guide right now. We are also considering requiring submitters to know who they are as purely AI generated PRs will not be allowed. A real person must review code. We're not saying this is a pure AI generated PR but you do not have much of a GitHub history (as you said) and we need to ensure you are not an agent. If you could let us know who you are in real life that would speed things up.

[scollis]

Great! And greetings! And thanks for the AI disclosure. We'll get to this soon.

[Yuxiang-Ren-HUB]

Thanks for the reply, and for taking the time to check.
I'm a graduate student in atmospheric science in China and I use Py-ART
in my own radar work, which is how I ran into this. get_nexrad_location
was writing the converted elevation back into the shared NEXRAD_LOCATIONS
dict, so a second call for the same station came back wrong (KTLX:
369.72 m, then 112.69 m). I reproduced it, wrote the fix and the tests,
and ran them locally before opening the PR.
I'm a real person, not an agent. I did use an AI assistant while writing
the patch, but the bug, the fix and the tests are ones I checked myself.

[Yuxiang-Ren-HUB]

Thank you, much appreciated.

[RBhupi]

I think the behavior table values changes should be preserved as some code in the wild may be relying on it. We may add units to know if the height is already changed in meters or not. If yes then conversion will return the values but will not change it back in the table again. This will preserved the behavior.