Convert wavenumbers to Hz, not GHz - #1904

convertor(x, "wavenumber", "Hz") multiplies by 29.9792458, which is c expressed in GHz per cm⁻¹, so the result is 1e9 too small for the unit the key names. With c = 299792458 m/s (exact, SI) and 1 cm⁻¹ = 100 m⁻¹, one wavenumber is 2.99792458e10 Hz.

Cross-check that stays inside the table: on master, convertor(convertor(1, "hartree", "wavenumber"), "wavenumber", "Hz") gives 6.5797e6, against the CODATA 2010 hartree–hertz relationship of 6.579683920729e15.

Why it survived: nothing in cclib calls this key — nuclear.rotational_constants builds its own cm⁻¹↔GHz factor from scipy.constants — and test_pairs only checks unit pairs that have both directions in the table. Hz has no inverse entry, so it sits outside the only test that looks at these values.

There is a second defensible remedy and I would rather name it than hide it: rename the key to wavenumber_to_GHz and keep the number, which is the shape #461 got (hartree_to_kcal → hartree_to_kcal/mol). I went the other way because Hz is a real unit, every other key in the dict returns the unit it names, and a GHz path already exists in nuclear.py. Happy to flip it if you prefer the rename.

Ran pytest test/parser test/method test/io on master and on the branch in the same venv: 0 failed / 204 passed / 5 skipped → 205 passed. An earlier version of this description reported 17 failures on both legs; those came from an under-provisioned checkout rather than from the suite. ruff check and ruff format --check clean at the pinned 0.15.22. Reverting the constant fails the new test; renaming the key to GHz fails it; a rounded 3.0e10 fails it.

AI assistance: this change was drafted with Claude Opus 5 (claude-opus-5).