JPL Horizons Harvester fails to handle object with multiple id's

[talister]

Describe the bug
Some solar system objects, mainly troublesome (periodic) comets, have multiple orbital element sets and/or multiple fragments and therefore have different SPK record numbers in the JPL Horizons system which have to be selected between. Attempting to add one of these objects through the TOM Toolkit's Catalog Search functionality results in nothing being added as the thrown ValueError is caught by an except and self.catalog_data is set to a blank dictionary.

To Reproduce
Steps to reproduce the behavior:

1. Go to 'Targets->Create Targets->Catalog Search'
2. Select 'JPL Horizons' as the Service and enter '323P' in the Term box
3. Click search
4. See the 'Object not found' error

This behavior can be seen more easily in the Python/Django shell:

from astroquery.jplhorizons import Horizons
term='323P'
obj = Horizons(id=term, location=None, epochs=None)
elements = obj.elements()
ValueError: Ambiguous target name; provide unique id:
    Record #  Epoch-yr  >MATCH DESIG<  Primary Desig  Name  
    --------  --------  -------------  -------------  -------------------------
    90001289    2006    323P           323P            SOHO
    90001290    2010    323P           323P            SOHO
    90001291    2021    323P           323P            SOHO
    90001292    2021    323P-B         323P-B          SOHO
    90001293    2021    323P-C         323P-C          SOHO

term='67P'
obj = Horizons(id=term, location=None, epochs=None)
elements = obj.elements()
ValueError: Ambiguous target name; provide unique id:
    Record #  Epoch-yr  >MATCH DESIG<  Primary Desig  Name  
    --------  --------  -------------  -------------  -------------------------
    90000694    1969    67P            67P             Churyumov-Gerasimenko
    90000695    1976    67P            67P             Churyumov-Gerasimenko
    90000696    1982    67P            67P             Churyumov-Gerasimenko
    90000697    1989    67P            67P             Churyumov-Gerasimenko
    90000698    1995    67P            67P             Churyumov-Gerasimenko
    90000699    2002    67P            67P             Churyumov-Gerasimenko
    90000700    2006    67P            67P             Churyumov-Gerasimenko
    90000701    2013    67P            67P             Churyumov-Gerasimenko
    90000702    2015    67P            67P             Churyumov-Gerasimenko

Expected behavior
The elements main body (not fragment) with the epoch of elements closest to the current time should be returned

Desktop (please complete the following information):

• OS: Rocky Linux 9.5
• Browser: Firefox
• Version: 128.7.0esr (64-bit
• Python Version: 3.11.9

Additional context
This problem is not OS/browser specific since it originates in the Horizons service itself e.g. with the original telnet service. I have code in NEOexchange that can catch and parse the table and requery on the specific SPK id that is closest in time.