feature: service accounts have a display name and a description, which the router sets for its internal ones.

ADR.md

@@ -465,11 +465,14 @@ Decision: The package defines its schema, `cn=vpn-router,cn=schema,cn=config`, w
 `vpnrouter_ldap.provision` adds when missing and keeps as `SCHEMA_ATTRIBUTE_TYPES` and
 `SCHEMA_OBJECT_CLASSES`. Its OID is `2.25.98477352595735834532404256531620013001`, made from a
 random UUID under the arc 2.25 (ITU-T X.667), which needs no registration; attribute types are
-under `.1` and object classes under `.2`. The first version has the attribute `vpnRouterScope`
-(multi-valued, case-insensitive strings) and the auxiliary class `vpnRouterAccount`,
-`MAY ( mail $ vpnRouterScope )`. Manager-only accounts have the class from their creation, so an
-e-mail address can be added later without changing their classes; VPN users get it once scopes are
-used.
+under `.1` and object classes under `.2`. It has the attribute `vpnRouterScope` (multi-valued,
+case-insensitive strings) and the auxiliary class `vpnRouterAccount`,
+`MAY ( mail $ vpnRouterScope $ displayName $ description )`; `displayName` and `description`, the
+standard attributes, are the display name and the description of a service account, which
+`account` cannot hold. Manager-only accounts have the class from their creation, so an e-mail
+address can be added later without changing their classes; VPN users get it once scopes are used.
+`vpnrouter_ldap.provision` replaces the definitions in `cn=config` that differ, so an extended class
+reaches an existing directory at the next setup run.
 
 Consequences: The schema check stays strict. New attributes extend `vpnRouterAccount`, and their
 OIDs continue the arcs. The scope `service` marks a service account (ADR-23). The OID must never
@@ -572,9 +575,11 @@ which another system signs in with to use a router service. Administrators add s
 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. 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
+administrator manages with the users. A service account has a display name and a description
+besides its name, so an administrator can tell what each is for. Internal service accounts are
+those the router creates and manages for its own services (`vpnrouter_users.internal_accounts`),
+with every property, display name and description included, so the system, not an
+administrator, owns them; at present that is the metrics service's, which setup names Metrics. `/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