Handle nscf outputs that lack the scf-Fermi stdout marker

[elinscott]

Problem

get_fermi_energy_from_nscf extracts the scf Fermi energy from an nscf run by matching the stdout line (compare with: X eV, computed in scf). That companion line is not always present, so the helper silently returned None. The None then flowed through prepare_wannier90_pp_inputs into the wannier90 input parameters, where the .win writer finally failed with an opaque Invalid value passed, accepts only bools, ints, floats and strings.

As per the QE source (PW/src/print_ks_energies.f90, print_ks_ef_homolumo), the single-value marker the regex matches is emitted only for a metallic (smearing/tetrahedra), single-Fermi-energy nscf run: insulators print HOMO/LUMO instead, and constrained-magnetization (tot_magnetization) runs print a two-value variant that the regex does not match. This is governed by the occupation/spin type of the nscf run, not by the QE version — the print_ef_scf guard is unconditionally true for nscf runs, identically in the 7.4.1, 7.5 and 7.6-dev sources I checked.

Changes

• get_fermi_energy_from_nscf falls back to the Fermi energy the parser extracted into the nscf's output_parameters when the stdout marker is absent, and its return type annotation is corrected to Optional[float] (it could already return None on a failed match). The fallback also handles constrained-magnetization runs, which report one Fermi level per channel, by taking max(fermi_up, fermi_down) as a conservative reference for the frozen windows.
• The fallback guards on fermi_energy_units == "eV", mirroring get_fermi_energy, so a value in the wrong unit cannot be returned silently (the aiida-quantumespresso parser always stores eV, so this is a latent-trap guard rather than a behavioural change).
• prepare_wannier90_pp_inputs raises a descriptive ValueError if the Fermi energy still resolves to None, instead of passing it through to the .win writer. The plotting helper get_workchain_fermi_energy (utils/workflows/plot/bands.py), whose nscf branches consume the same value, gains the same guard.
• Unit tests for get_fermi_energy_from_nscf cover the marker-present path, the fallback to the parsed nscf Fermi energy, the spin-polarised max(up, down) branch, the None-when-nothing-available case, and the non-eV units guard.

Notes

The stdout marker remains the first choice where present, preserving current behaviour where the current machinery works (the marker reports the scf Fermi energy, which can differ from the nscf one).

Design question

Shouldn't this Fermi energy come from the nscf in the first place — always, not just as a fallback? The value feeds shift_energy_windows applied against the nscf eigenvalues, so surely its fermi level should be our reference? It will also typically be a more accurate reference, evaluated with better Brillouin-zone sampling cf. the scf.

However, using the nscf fermi level by default would be a breaking change, shifting the reference for every user rather than just skip-scf runs (cf. this PR, which keeps behaviour unchanged where the current machinery works.)

Testing

Exercised end-to-end against pw.x 7.6-dev nscf output: previously the wannier90 calculation excepted in presubmit; with the fallback the pp run receives the parsed Fermi energy and completes.

[elinscott]

test_scdm was failing here with ValueError: Fermi energy resolved to None. The mock is at fault, not the guard: its scf output_parameters set fermi_energy without fermi_energy_units, so get_fermi_energy returned None. Real data never looks like that — aiida-quantumespresso writes the value and its units together, and all 23 of its pw parser fixtures carry both. Before this PR that None went into the wannier90 parameters unchecked, so the test was asserting the behavior the PR removes.

Pushed: the mock gains its units, and the test now asserts the Fermi energy actually reaches wannier90.parameters.