set_name: return null instead of substituting the manufacturer, category or class identifier

[alistair3149]

The problem

related_items.set_name is populated from several different concepts, so it can't be used to identify a set.

set_name actually holds	example value	applied to	other instances
the manufacturer	"RRS"	all 66 Arden-* items	HardinTactical on 30/30 Bellator Jacket*, NavySurplus on 24/24 Bobcat Bomber Jacket*
the category	"Sneakers"	all 25 Edgeriders Shoes items	RadiationSuit on 20/20 Stirling Exploration Helmet*; 23 more set names are bare type labels, e.g. Internal Tank across 47 base items and Seat across 42
a different set	"ORC-mkX"	the four GCD-Army pieces — Arms, Core, Helmet, Legs	ADP-mk4 on 33 of its 62 items, which are DCP Armor pieces; Tehachapi on 21/21 Aztalan pieces
an internal class identifier	"arma_barrel_stab_s1"	Emod Stabilizer1 and its siblings	41 items; looks like a fallback firing when no display name resolves

In total, 124 set names covering 903 items carry a value whose stem appears in neither the item's own name nor its base_item's name. That test is a heuristic and will have false positives, but the four shapes above are unambiguous.

Two things that make it hard to work around

The first two substitutions return nothing new. They duplicate a field already on the same record, so they cost the reliability of set_name and add no information:

item	set_name	already present as
Arden-CL Backpack	"RRS"	manufacturer.code = "RRS", the identical string
Edgeriders Shoes	"Sneakers"	type_label = "Shoes", classification = "FPS.Clothing.Shoes"

The third contradicts the same record. The GCD-Army pieces have a correct base_item — GCD-Army Arms points at itself — sitting beside a set_name naming a different set. Two fields on one record, two answers, and nothing marks which to trust.

Sets containing one item

Separately, 305 items carry a set_name while both variant_items and set_items are empty, so the set has a single member. Some of those values aren't sets at all, e.g. set_name: "2954" (a year) on 2954 Luck's Favor Tankard.

Suggested fix

Return null rather than substituting a different concept. A null is trivial for a consumer to handle; a plausible-looking wrong value fails silently, because nothing on the record marks which kind of value you received. Since the manufacturer and category fallbacks duplicate manufacturer.code and type_label / classification, nothing is lost by dropping them, and the same change would cover the leaked class identifiers.

Reproducing these numbers

Full sweep on 18 September 2026 — the list endpoint accepts the include, so no per-UUID fetching is needed:

GET /api/v2/items?limit=200&page=N&include=related_items&locale=en_EN

62 pages, 12,331 items, no duplicate UUIDs. set_name is present on 6,098 of them (49.5%).

Every item name above links to its record at /api/v2/items/<uuid>?include=related_items&locale=en_EN.