GET leo/iaas/service-roles returns duplicate entries (80 rows, 35 unique roles)

[yakari007]

Summary

GET leo/iaas/service-roles currently returns 80 entries, but they collapse
to only 35 distinct name/description/config combinations. Every entry
has a unique id, but many share identical name + description +
config content with a different id - e.g. two caddy entries with the
exact same description and config schema, differing only in id
(c38d4f34-b6c2-4076-8207-01530a0c68f7 vs
d9c9e9c1-5cf8-4a94-9f45-6bd3448c476a).

Duplication pattern

Repeat counts per role name aren't uniform - they range from 1x (roles that
look newly added) up to 4x:

4x: opensearch, php-fpm, prometheus, rabbitmq, vault
3x: influxdb, jenkins, kafka, keycloak, loki, minio, mongodb, mosquitto, nats-server, node_exporter
2x: caddy, fail2ban, mariadb, mysql, nginx, postgresql, redis, tailscale, traefik, ufw
1x: alertmanager, alloy, bind9, coredns, docker, docker-registry, elasticsearch, gitlab-runner, grafana, haproxy

The roles with more copies are the ones that have existed longest (the
original 11-role catalog and its early additions); the 1x roles are the
most recently added ones. That pattern - increasing duplicate count
correlating with how long a role has existed - looks like each
deploy/migration re-inserting the full role catalog without a uniqueness
constraint on name, rather than 80 intentionally distinct roles.

Repro

curl -s "$LEO_BASE_URL/leo/iaas/service-roles" -H "Authorization: Bearer $LEO_API_TOKEN" \
  | python3 -c "
import sys, json, collections
d = json.load(sys.stdin)
roles = d['data']
counts = collections.Counter(r['name'] for r in roles)
print('total entries:', len(roles), '- unique names:', len(counts))
"

Confirmed stable across two separate checks minutes apart (same 80/35
split, same per-name counts both times) - not an in-flight migration or a
transient blip.

Impact

Any client that iterates this list and treats each entry as a role to
install/test/display ends up doing 80 units of work for what should be 35 -
leo4.tester's iaas-service-roles scenario now dedupes client-side by
name to work around this, but that's a workaround, not a fix.

Found via leo4.tester's iaas-service-roles automated test scenario.

[yakari007]

Also outside this repo's scope — toolkit doesn't contain the GET leo/iaas/service-roles API endpoint or its backing database; it only holds the Ansible role source files under capabilities/service-roles/ (which are 1 directory per role, no duplication here). The duplicate-rows-on-repeated-catalog-sync pattern you describe points at the leo backend's sync/migration job (whatever ingests this repo's roles into its DB) missing a uniqueness constraint on name. Flagging so it can be routed to the leo/backend repo.