Web dashboard: 'pending' status is confusing for models not in active set

[stgreenb]

Problem description

The web dashboard shows all 157 models from the catalog, but only models in the active set are actually probed. The other 152 models show as "pending" forever, which confuses users into thinking the testing is broken.

Current behavior

• Dashboard shows 157 models with statuses: "up", "down", "pending"
• Only models in the active set (default: 5 models) are probed
• Models not in the active set stay "pending" indefinitely
• No visual distinction between "pending because testing is in progress" vs "pending because not in set"

Expected behavior

Users should clearly understand:

1. Which models are being tested (in active set)
2. Which models are not being tested (not in active set)
3. Why a model shows "pending"

Suggested improvements

1. Visual distinction: Add an icon or label to models not in the active set (e.g., "not in set" badge)
2. Clarify "pending": Show "pending (not in set)" vs "pending (testing...)"
3. Filter by set: Add a filter to show only models in the active set
4. Tooltip: Hovering over "pending" shows why (e.g., "This model is not in your active router set")

Impact

• Users think the testing is broken when it's actually working as designed
• New users don't understand why some models show "pending" forever
• Confusion leads to support requests and frustration

Notes

This affects all surfaces (CLI, Docker, Desktop) since the model list rendering is shared.

[vava-nessa]

Thanks for the report @stgreenb — totally valid UX gap.

Fix

The inRouterSet field was already exposed by the daemon payload but the frontend never used it for visual differentiation. Here's what changed:

Web Dashboard:

• Models with status: pending AND inRouterSet: false now show "NOT IN SET" (dim gray icon/text) instead of "⏳ wait" (yellow animated)
• StatusDot renders a static dim gray dot instead of the pulsing yellow one
• The entire table row gets opacity: 0.6 to visually separate "not being tested" from "actively loading"
• Hover restores full opacity so the row is still readable

Web server (web/server.js):

• serializeModel() now computes and exposes inRouterSet from the active router set, so the local dev dashboard also gets the field (previously only the Docker daemon had it)

No TUI changes needed — the TUI pings ALL models, so they never stay "pending" forever. The issue is Docker/daemon-only where only active-set models get probed.

No new dependencies. The inRouterSet boolean was already in the data, just not wired to the UI. Will ship in the next release.