Let a grouping span values and target ecosystems

[irskep]

Just fixing some issues I found while implementing Atticus's equivalent of surfaces in our Dependicus installation. This is an expansion of the API and doesn't break backward compat.

The reason I'm hitting this and you didn't is because I want to allow a dependency to "roll up" to more than one place. Having fractal single-owner surfaces is great, but not everybody is going to do that.

---

Closes #111, closes #112. Both are backward compatible: the 930 existing tests pass untouched.

getValue may return several values

A grouping filed each dependency under exactly one value, which makes it a partition. That fits an assigned dimension, where someone has decided each dependency's owner, which is what the dependencyOwners map in the plugin docs shows. It doesn't fit a derived one whose membership overlaps.

I group dependencies by the team that owns the code using them, read off usedBy. Four apps across three teams use @apollo/client, and all three are genuinely on the hook for it. A single grouping had to pick one team and the other two lost the dependency from their page. Returning a readonly string[] files it under each; a single string behaves exactly as before, so assigned dimensions need no change.

To be clear about what this is not for, since I had it wrong at first: drill-down already works without it. GroupingStat.url, GroupingSection.html and GroupingFlag.detailLink all render as links, so a team page can link to surface pages and a surface page to individual dependencies. This is only about one dependency belonging to several groups at the same level.

ecosystems limits a grouping to where it can be computed

Groupings render for every provider, so one that only works for a single ecosystem still gets an index page and a nav link under the others, showing no entries. usedBy names workspace packages under the pnpm provider; the go provider reports one consumer for the whole module, so team ownership can't be derived there at all. ecosystems: ['npm'] skips the grouping for other providers and leaves it out of their nav. Omitting the field keeps today's behavior.

The nav was the fiddly half, as #111 guessed. Three methods built the list from this.groupings; they now go through one helper, and each passes the ecosystem it already had in scope, so no signatures changed except an optional trailing argument on toGroupingPages.

Checked against a real monorepo

26 packages across 5 teams, 241 npm dependencies and 117 Go modules. Before, working around single-value with a grouping per team: 5 nav links, 5 one-entry index pages, and 5 empty team pages under the go tab. After, with one grouping: a single nav link, one index listing all 5 teams with their counts, a page per team carrying its shared dependencies too, and nothing rendered under go.

🤖 Generated with Claude Code