[youdie006]

#227 fixed MGF peak lines that have only an m/z. MS1Base._handle_peak has the same pattern: it appends the m/z, then float(sline[1]) raises IndexError, which is swallowed, so the intensity array is one short and every later intensity belongs to the wrong m/z. MS2Base._handle_peak calls it first, so MS2 has it too.

The same MS2 function also reads sline[3] for the resolution after only checking len(sline) > 2, so a peak line m/z intensity charge (charge is documented as the third column, resolution as the fourth) raises a bare IndexError with the default read_resolutions=True.

MS1, a line "150" without intensity between "100 1" and "200 3"
  before: 'm/z array': [100.0, 150.0, 200.0], 'intensity array': [1.0, 3.0]
  after:  'm/z array': [100.0, 150.0, 200.0], 'intensity array': [1.0, nan, 3.0]

MS2, peak lines "100 1 1" and "200 3 2" (no resolution column)
  before: IndexError: list index out of range   (also with read_charges=False)
  after:  'charge array': [1, 2], 'resolution array': [0, 0]

The MS1 change mirrors 53ad9c4 (NaN intensity, append after parsing). For MS2 the existing else: append(0) now applies when the resolution column is missing. Lines with all columns, and both test files, parse exactly as before. As with MGF since #227, an integer intensity dtype now raises on an m/z-only line instead of misaligning.

Tests: test_mz_only_peak_lines in test_ms1.py and test_ms2.py (modelled on the MGF one) and test_peak_lines_without_resolution in test_ms2.py; they fail without the change. test_ms1.py, test_ms2.py and test_mgf.py pass locally on Python 3.12, and the full test directory passed except the PostgreSQL Unimod test, which needs a server.

Written with AI assistance (Claude); I have reviewed the change.