[Manager] Improve extension discovery with GitHub stars, repository links, and trust filters ⭐

### What problem are you experiencing?

The **Nodes Manager** gallery makes it difficult to evaluate unfamiliar extensions before installing them.

Cards currently emphasize download counts, but downloads alone do not provide enough context about an extension’s community adoption, maintenance status, source repository, or relative maturity. Users often need to search for the project manually on GitHub before deciding whether it is relevant or trustworthy.

This is especially noticeable when browsing many similarly named node packs. A few additional signals could make the gallery much more useful without turning it into a popularity contest. 🔎

### When does this problem occur?

This happens whenever I browse **All Extensions** or **Not Installed** looking for new node packs.

The typical workflow is:

1. Find a potentially useful extension.
2. Search its name manually on GitHub.
3. Verify that the repository is active and belongs to the expected maintainer.
4. Check stars, documentation, recent activity, issues, and releases.
5. Return to Nodes Manager and install it.

Repeating this process for several extensions makes discovery unnecessarily slow and leaves newer or specialized projects difficult to evaluate.

### How often do you encounter this problem?

Several times per week

### How much does this problem affect your workflow?

Causes moderate inconvenience

### Current workarounds

I manually search GitHub for each extension and compare the repository with the information shown in Nodes Manager.

Sorting by downloads helps identify established projects, but it is a very limited proxy: it does not reveal whether the repository is active, well documented, or receiving community interest.****

### Ideas for solutions (Optional)

Some possible improvements:

- ⭐ Display the repository’s GitHub star count on each card.
- 🔗 Add a clearly visible **Open repository** link or GitHub icon.
- Add sorting options such as **GitHub stars**, **recently updated**, and **downloads**.
- Add an optional **Established extensions only** filter that hides projects below a configurable adoption threshold—for example, fewer than 100 downloads.
- Alternatively, show a neutral **Low adoption / New project** badge instead of hiding those projects.
- Display the last repository update or latest release date when available.
- Keep stars and downloads clearly labeled as popularity/adoption signals, not security guarantees.
- If reliable data exists, show separate trust indicators such as verified ownership, registry validation, or security-scan status.

I would avoid labeling low-download projects as “_unsafe_.” Legitimate new extensions necessarily begin with zero downloads, so hiding them by default would create a discovery cold-start problem.

A configurable filter or neutral badge would let cautious users narrow the results without penalizing new maintainers.

**Questions for maintainers and the community:**

- Which signals would actually help you decide whether to inspect or install an extension?
- Should low-adoption filtering be opt-in, or enabled by default?
- Would GitHub stars be useful enough to justify API caching and rate-limit considerations?

### Additional context

Here is an example of the current Nodes Manager gallery, where downloads are visible but repository **stars** and direct repository links are not:

#### Existing precedent: Comfy Registry

For comparison, Comfy Registry already displays GitHub star counts alongside downloads on its extension cards:

This provides a useful precedent within the ComfyUI ecosystem. Users can compare two different adoption signals at a glance, and the additional metadata does not make the cards noticeably more crowded. While Nodes Manager may use a different data source, the Registry demonstrates that this information can fit naturally into an extension gallery.

For transparency, I maintain the four extensions shown in these screenshots. They provide concrete examples because their adoption levels differ, while all four are actively maintained:

- [OpenPose Studio](https://github.com/andreszs/ComfyUI-OpenPose-Studio) — visual OpenPose creation and editing
- [Ultralytics Studio](https://github.com/andreszs/ComfyUI-Ultralytics-Studio) — Ultralytics-based vision workflows
- [Styler Pipeline](https://github.com/andreszs/ComfyUI-Styler-Pipeline) — style suggestions and conditioning workflows
- [LoRA Pipeline](https://github.com/andreszs/ComfyUI-Lora-Pipeline) — area-based LoRA scheduling and conditioning

These links are included as reproducible examples, not as a request to promote specific extensions. The proposed metadata and filters should work consistently for every project in the registry.

I would be interested to hear how other users currently judge unfamiliar extensions and which two or three signals would provide the most value without making the cards too crowded. 💬

Start with the Nodes Manager gallery in the All Extensions and Not Installed views, then compare its cards with the Comfy Registry precedent described in the issue. Clarify which signals, links, sorting, and filters are in scope before changing anything. Done means the agreed metadata and discovery controls are available consistently without presenting popularity as a security guarantee.

Written by the indexing model from the issue text.