fix: internal service accounts are the router's own, of which the metrics service's is the one at present, and the documentation says what a service account is.

ADR.md

@@ -558,7 +558,7 @@ purge. A view shows only what its level keeps, so a shorter retention empties th
 view. A month view needs the hourly rows and a year view the monthly rows. `/metrics` has only the
 last sample; history is not scraped.
 
-## ADR-23: /metrics takes HTTP Basic authentication of an internal service account that setup creates
+## ADR-23: /metrics takes HTTP Basic authentication of an internal service account the router manages
 
 Status: Accepted
 
@@ -567,20 +567,21 @@ the router's tokens, which last minutes (ADR-3). The scraper should not be able
 API or the Manager, and its password should be checked and locked out like any other. The account
 belongs to the package's metrics, not to the people using the router.
 
-Decision: A service account is a Manager-only account (ADR-18) with `vpnRouterScope` `service`.
-Administrators add service accounts with `vpn-router-user add --service` and the web service's
-`/service-accounts`, for services of their own that check passwords against the directory.
+Decision: A service account is a Manager-only account (ADR-18) with `vpnRouterScope` `service`,
+which another system signs in with to use a router service. Administrators add service accounts
+with `vpn-router-user add --service` and the web service's `/service-accounts`.
 `/service-accounts` is a path of its own, apart from `/users`, which does not list or serve them:
 a service account has no names, certificate, profile or TOTP, and is not a person an
-administrator manages with the users. The metrics service's is the internal one, created by
-`vpn-router-setup`: while metrics are enabled it adds the account `metrics.service_account` names,
-`metrics` by default, with a random password it writes to `/etc/vpn-router/metrics.secret` (root
-only), and sets a new random password, ending a lockout, when the file is missing or no longer
-holds the password. `/service-accounts` marks it as `internal` and only lists it: every other
-request on it, and putting it in or taking it out of a group at `/groups`, gets 403, whatever the
-token. Setup
-changes it through the directory's user-manager account, not the API, and root may still with
-`vpn-router-user`. `/auth` refuses every service account with the message of a wrong password. `/metrics` accepts HTTP Basic only for that account, and
+administrator manages with the users. Internal service accounts are those the router creates and
+manages for its own services (`vpnrouter_users.internal_accounts`), so the system, not an
+administrator, owns them; at present that is the metrics service's. `/service-accounts` marks
+them as `internal` and only lists them: every other request on one, and putting one in or taking
+one out of a group at `/groups`, gets 403, whatever the token. The router changes them through the
+directory's user-manager account, not the API, and root may still with `vpn-router-user`. For the
+metrics service, `vpn-router-setup` adds the account `metrics.service_account` names, `metrics` by
+default, while metrics are enabled, with a random password it writes to
+`/etc/vpn-router/metrics.secret` (root only), and sets a new random password, ending a lockout,
+when the file is missing or no longer holds the password. `/auth` refuses every service account with the message of a wrong password. `/metrics` accepts HTTP Basic only for that account, and
 only when it is a service account; the password is checked with a bind as the account, so the
 password policy's lockout applies (ADR-14). TLS is Caddy's, on `metrics.https_port` (ADR-21);
 plain HTTP is served on the interfaces `metrics.listen` names, `internal` by default.