Each label on Settings › Labels says how many open issues and pulls carry it, as a link to the issues list narrowed to it #7866

An admin tidying labels on /:owner/:name/settings/labels cannot see which labels are in use. They delete blind, and they cannot get from a label to its work without retyping it as a filter. The issues list already narrows by ?label= (src/web/studio/lists.ts facets).

Done:

• [ ] Each row on the labels page shows N open beside its chip: the count of open issues and pulls that carry the label. It is a link to /:owner/:name/issues?label=<name> (encoded). At 0 it reads unused and is not a link.
• [ ] All the counts come from one grouped query, a new openLabelCounts(db, repoId) in src/core/issues.ts that returns Map<labelId, number>. The page does not run one query per label, and its server-timing gains a counts phase.
• [ ] Sealed issues the viewer cannot see are not counted. The page is admin-only, so state in a comment why that holds, or reuse the sealedScope rule.
• [ ] Delete's confirm says how many open items lose the label when it is above 0, e.g. "Delete bug? 3 open items carry it."
• [ ] test/labels-page-counts.test.ts: two labels, one on two open issues and one closed issue, one on none. The page says 2 open, links to ?label=, says unused for the other, and the confirm names the count. Each check fails without the change.
• [ ] bun scripts/design-lint.ts is clean. Any new class is named in docs/design/areas/settings.md, never in docs/DESIGN.md.

Files: src/web/pages/labels.ts, src/core/issues.ts, test/labels-page-counts.test.ts, docs/design/areas/settings.md. Risks: the page must still answer in milliseconds on trevato/forge (thousands of issues). Use one GROUP BY label_id joined to open issues, on the indexes that exist. Builder: scout or torque (web page plus one query).

Parked by the crew: the check stayed red through 2 automatic tries (pull #7894 closed). Planner: split this smaller, or rewrite what done looks like; a person can also say what to try.