Fragments of provisionally desiginated comets break the Horizons id determination

[talister]

In horizons_ephem we have exceptions to catch the case of an ambiguous target name coming back from JPL Horizons for the case of comets with multiple element sets or fragments. This works fine for permanent designations e.g. 73P and its many pieces but breaks for C/2025 K1 and its 3 fragments. This is because when we split the returned lines on whitespace in determine_horizons_id() the designation gets split over two chunks and can't be matched:

In [104]: lines
Out[104]: 
['Ambiguous target name; provide unique id:',
 '    Record #  Epoch-yr  >MATCH DESIG<  Primary Desig  Name  ',
 '    --------  --------  -------------  -------------  -------------------------',
 '    90004909    2025    C/2025 K1      C/2025 K1       ATLAS',
 '    90004910    2025    C/2025 K1-B    C/2025 K1-B     ATLAS',
 '    90004911    2025    C/2025 K1-C    C/2025 K1-C     ATLAS',
 '']

With the standard split, we have the following chunks and we're expecting the full name in chunks[3]:

['Ambiguous', 'target', 'name;', 'provide', 'unique', 'id:']
['Record', '#', 'Epoch-yr', '>MATCH', 'DESIG<', 'Primary', 'Desig', 'Name']
['--------', '--------', '-------------', '-------------', '-------------------------']
['90004909', '2025', 'C/2025', 'K1', 'C/2025', 'K1', 'ATLAS']
['90004910', '2025', 'C/2025', 'K1-B', 'C/2025', 'K1-B', 'ATLAS']
['90004911', '2025', 'C/2025', 'K1-C', 'C/2025', 'K1-C', 'ATLAS']
# chunk0        1             2             3            4           5         6

In this case what we want is now in chunks[4] and chunks[5]
A solution may be to split on the 3 spaces between columns and offset the column chunks by 1 to skip the blank intro set of 3 spaces
Why is it always comets...