Show Maven local upstreams in the registry upstream list

What does this MR do and why?

A Maven virtual registry with a local upstream shows "No upstreams yet". The upstreams query selects upstream, which is non-null and errors on a local row, so the whole registry resolves to null. The backend in !253638 (merged) (merged and included in the 19.5 release) added targetUpstream, which returns a MavenUpstream or a MavenLocalUpstream for every row. This MR switches the frontend to it.

• The Maven upstreams query selects only targetUpstream. It no longer selects upstream.
• Local rows show the upstream name and the target group or project path. The name is not a link, and Edit and Clear cache are hidden, because local upstreams have no detail page, edit page or cache endpoint. Reorder and Remove act on the registry upstream row, so they stay.
• Link upstream compares the group's remote upstream count with the remote rows only, and the link form excludes only already linked remotes.
• Clear all caches is shown only when the registry has a remote row. Its confirmation now says it clears exclusive remote upstreams, which matches Registry#purge_cache!.
• Container virtual registries share these components and still read upstream, so they are unchanged.

This must ship in a later release than the backend.

Why there is no @gl_introduced tag

The backend merged on 2026-10-12. If it is in the 19.5 release, this MR can merge in 19.6. If it misses the 19.5 stable branch, this MR moves to 19.7. Either way, every backend this frontend runs against already has targetUpstream, so the tag would never strip anything.

Edit: Backend MR has been included in 19.5

References

• Related to #611501
• Backend: !253638 (merged)

Screenshots or screen recordings

Before	After

More recordings are in the Recordings section below.

How to set up and validate locally

1. In a top-level group, create a Maven virtual registry with a remote upstream, and confirm the upstream list renders.
2. Attach a local upstream that targets a group or project.
3. Reload the registry page. Both rows render in position order, the local row shows its target path, and Edit and Clear cache appear only on the remote row.
4. Open Add upstream > Link existing upstream. The list keeps every row, and the selector offers only remote upstreams that are not linked yet.
5. Open a container virtual registry and confirm its upstream list is unchanged.

Recordings

Recorded on the GDK. A is master at f978a5ff20d31d, which already has the backend. The others are this branch at 6ee2aa0f042c77. Reorder is checked against Postgres after each click.

A. Before: one local upstream hides every row

D1. After: remote and local upstreams together, in position order. Local rows show the target path, and their names are not links

D2. Edit and Clear cache appear on the 3 remote rows only. Remove and reorder appear on all 5

D3. Remote-only registry with 20 upstreams, unchanged

D4. Viewer who cannot read the local targets: the names show, the paths do not

D5. Reorder across remote and local rows

D6. Link upstream: the group has 4 remotes, the registry links 3 plus 2 local upstreams. Link is offered and only the unlinked remote can be picked

D7. Clear all caches confirmation names exclusive remote upstreams

C1. Container registry upstreams, unchanged

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

🤖 Generated with Claude Code