[Bug] Manage Lineage search sends display label `Data Product` instead of `DataProduct`, returning no link candidates

Start in src/frontend/src/components/common/lineage-editor.tsx around lines 311-323 and trace how targetType is used to build the link-candidate request. Add or update a focused test for the Manage Lineage search, asserting that a Data Product request uses target_type=DataProduct and returns candidates. Done means the wizard sends the machine type name rather than the display label.

In simple terms

In the Manage Lineage wizard there's a search box for finding a data product to link to. The backend search works fine — if you ask it for target_type=DataProduct, it correctly returns matches like "Customer 360". But the frontend sends the wrong value: instead of the machine name DataProduct, it sends the human-readable label Data Product (with a space). The backend matches the type by exact spelling, so "Data Product" matches nothing and the search silently comes back empty. To the user it looks like there are no products to link, even though they exist and the API would happily return them.

Current Behavior

The Manage Lineage wizard's link-candidate search returns no results for data products, even though the backend endpoint returns matches when called correctly. The wizard sends target_type=Data Product (the display label, with a space) rather than target_type=DataProduct (the type name). The backend matches the dedicated type by exact string equality (== "DataProduct"), so the spaced label matches nothing and the candidate list is empty.

Evidence:

1. Frontend derives targetType from the display label, not the type name — src/frontend/src/components/common/lineage-editor.tsx:311:

   const targetType = relationship.target_type_label || relationship.target_type_iri.split('#').pop() || '';
   

   It prefers target_type_label; the correct fallback (target_type_iri.split('#').pop() → "DataProduct") is only used when the label is absent.

2. target_type_label is the RDFS label "Data Product" (with a space) — built at src/backend/src/controller/ontology_schema_manager.py:363,372 from rdfs:label, and the ontology defines it with a space at src/backend/src/data/taxonomies/ontos-ontology.ttl:180-182:

   ontos:DataProduct a rdfs:Class ;
       rdfs:subClassOf ontos:Entity ;
       rdfs:label "Data Product"@en ;
   

3. The request the wizard builds — src/frontend/src/components/common/lineage-editor.tsx:317-323:

   const params = new URLSearchParams({
     target_type: targetType,   // "Data Product" ← wrong; should be "DataProduct"
     limit: '20',
   });
   

Known-good comparison: GET /api/suggestions/link-candidates?target_type=DataProduct&query=Customer returns "Customer 360". The same call with target_type=Data Product returns nothing.

Expected Behavior

The wizard should send the machine type name (DataProduct) as target_type, so link candidates are returned and selectable in the UI.

Steps To Reproduce

1. Open a data product (or lineage-capable entity) and launch the Manage Lineage wizard.
2. In the link-candidate search box, type a term that matches an existing data product (e.g. Customer).
3. Observe no candidates appear.
4. Compare with the backend directly: GET /api/suggestions/link-candidates?target_type=DataProduct&query=Customer returns "Customer 360", confirming the backend is healthy and the frontend is sending the wrong target_type.

Root cause summary

Frontend uses the RDFS display label ("Data Product", with a space) as target_type instead of the type name ("DataProduct"); the backend matches the type by exact string equality, so results are silently empty.

Suggested fix direction

Derive target_type from the type name (IRI local name / machine type), not the display label — e.g. reorder to prefer target_type_iri.split('#').pop(), or map label→type name before building the request. Add a test asserting the wizard requests target_type=DataProduct.

Suggested scope: scope/products (or ontology/lineage). Applying triage labels is up to maintainers.