hive-forge: enable the per-label and per-repository issue metrics

Turns on gitea_issues_by_label and gitea_issues_by_repository, gated on
behindGateway exactly like the metrics endpoint itself -- they are only
reachable through the authenticated location that condition creates.

These are off by default upstream because they are the only metrics in
this section whose series count grows with the CONTENT of the forge
rather than with its feature set, so the question is cardinality.
Measured rather than assumed: ~19 distinct labels and ~29 repos on this
instance, well under 100 series, against a store that took +2234 from
nine host scrapers.

Still no TOKEN. Forgejo can guard the endpoint with its own static
bearer, but the swarm authenticates the scraper at the gateway, and a
second per-service credential would be the one that stops getting
rotated -- the reasoning already recorded above ENABLED applies
unchanged to the breakdowns.

nix/host-modules/hive-forge/default.nix

@@ -757,6 +757,26 @@ in
               # service would buy nothing and would be the one that stops
               # getting rotated.
               metrics.ENABLED = cfg.behindGateway;
+              # The two per-dimension breakdowns, on the same condition as
+              # the endpoint itself: `gitea_issues_by_label{label=…}` and
+              # `gitea_issues_by_repository{repository=…}`. Off by default
+              # upstream because they are the only metrics here whose series
+              # count grows with the CONTENT of the forge rather than with
+              # its feature set — so the question is cardinality, and it was
+              # measured rather than assumed.
+              #
+              # Measured on this instance: ~19 distinct labels and ~29 repos
+              # ⇒ **well under 100 series**, against a store that took +2234
+              # from nine host scrapers. Two orders of magnitude below the
+              # cost that already argued against shipping a `process`
+              # scraper, so the breakdowns are affordable here.
+              #
+              # ⚠️ Both grow with repo and label count, not with traffic. A
+              # forge that grew to thousands of repos would want this
+              # revisited — that is a real trigger, unlike a time-based one:
+              # `count(gitea_issues_by_repository)` answers it directly.
+              metrics.ENABLED_ISSUE_BY_LABEL = cfg.behindGateway;
+              metrics.ENABLED_ISSUE_BY_REPOSITORY = cfg.behindGateway;
               # Repo migrations / pull-mirrors fetch from the source
               # URL *inside* Forgejo. hyperhive code is synced from
               # `localhost` (and the host LAN), which Forgejo's