Make revoking final, keep password rules in one place, drop a grant nobody read

Three credential and authz findings, all the same shape: a second path to a
decision, with weaker rules than the path built for it.

PUT /api/apitokens/<id> {"isactive": true} un-revoked a token, and the ORIGINAL
secret worked again - so "revoked" meant "paused until somebody flips it back",
for a credential whose secret is assumed to be out by the act of revoking it.
Revocation is one way now. Deactivating through the same route still works;
bringing one back does not, and the refusal says to mint a new token.

PUT /api/users/<self> accepted a `password` field with no current-password
proof and no length rule, while /api/auth/change-password requires both. When
two routes reach the same state the weaker one is the real rule, so the stronger
one was decoration. Changing your own password through the users route is
refused and points at the right endpoint. An ADMIN may still set one - that is
how a temporary password is issued - with the same 8-character floor, and
mustchangepassword is now set, because a password somebody else chose is
temporary by definition.

tools.secrets was declared guest-grantable, so the role grid offered it and
stored it, and the secure-send route never consulted the guest role at all: it
decides on securesend_allow_guests, which fails closed and carries the rate
limit. Ticking the box changed nothing in either direction, so the screen and
the behaviour disagreed. The declaration is gone; tools.view stays, because it
really does gate the nav entry.

Removing it needed care: update_role refuses the WHOLE request when a submitted
permission is not grantable, and the grid resubmits what the role already holds,
so a site whose guest role held tools.secrets could no longer save that role at
all - the deadlock fixed in 723a4ff, re-created from the other end. Migration
7d41 revokes the grant from the guest role, and nothing is lost because it
granted nothing.

Eight tests. The first two verified by planting: remove either guard and three
fail.

Scope: product

shopdb/core/api/apitokens.py

@@ -163,7 +163,18 @@ def update_apitoken(tokenid: int):
             return error_response(ErrorCodes.VALIDATION_ERROR, 'name cannot be empty')
         token.name = newname
     if 'isactive' in data:
-        token.isactive = bool(data['isactive'])
+        # Revocation is ONE WAY. A revoked token's secret is out there - that
+        # is why it was revoked - and re-activating the row made the same
+        # secret work again, so "revoked" meant "paused until somebody flips it
+        # back". Deactivating through this route is still allowed; bringing one
+        # back is not, and the answer says to mint a new one.
+        wanted = bool(data['isactive'])
+        if wanted and not token.isactive:
+            return error_response(
+                ErrorCodes.VALIDATION_ERROR,
+                'A revoked token cannot be re-activated - its secret is '
+                'already out. Create a new token instead.')
+        token.isactive = wanted
     if 'scopes' in data:
         scopelist, scope_error = _validate_scopes(data.get('scopes'), token.user)
         if scope_error is not None: