feat(limits): unconditional usage accounting

buildLimitScopes previously omitted a user or group scope entirely
whenever that entity had no configured Limits, so a limit-less
user/group never accumulated ANY usage counters. Root-caused live:
the admin dashboard's total kept climbing while every per-user row
stayed zero until an operator added phantom, unreachable
requestsPerDay limits everywhere just to make counters build at all.

buildLimitScopes now always builds a user and a group scope. Limits
still gate enforcement only: evaluateScope already no-ops on a nil
Limits field, so a limit-less scope is counted but never violates.

Update stale doc comments coupling accounting to configured limits
(evaluateScope, the integration alice fixture, routes_media_test.go,
routes_unified_test.go, admin_test.go's admin1 assertion) and add:
- TestBuildLimitScopes_AlwaysBuildsBothScopes: table-driven over
  every nil/non-nil user/group limits combination.
- TestAdminUsage_LimitlessUserAndGroup_AccumulateRealTraffic:
  end-to-end regression proving a limit-less user and group
  accumulate real request/token counters visible via
  GET /admin/api/usage.

integration/traefik/dynamic.yml.tmpl

@@ -83,13 +83,14 @@ http:
           users:
             inline:
               # limits.requestsPerDay is set (generously — every test in
-              # this suite together never approaches it) purely so
-              # buildLimitScopes (routes_unified.go/routes_media.go/
-              # admin.go) builds a "user" counter scope for alice at all:
-              # a nil per-user Limits means only the group's own counters
-              # ever increment, which would make the admin usage test's
-              # "alice's own request counters are > 0" assertion always
-              # read zero regardless of how much traffic she generated.
+              # this suite together never approaches it) to exercise real
+              # per-user ENFORCEMENT alongside accounting, not because it is
+              # required for alice's own counters to move at all: since the
+              # v0.21 accounting fix, buildLimitScopes (routes_unified.go/
+              # routes_media.go/admin.go) always builds a "user" counter
+              # scope, limits or not, so the admin usage test's "alice's own
+              # request counters are > 0" assertion would hold even with
+              # this field unset.
               - name: alice
                 group: eng
                 apiKey: "sk-int-alice"