Checked whether an automated test already existed for this manual test: there was none.
The closest existing test is DefaultAuthorizationManagerIntegrationTest#groupAccess, whose docDenyGroupA / docDenyGroupB documents deny all rights to a group at document level: the edit right is only covered incidentally there, nothing isolates it, and nothing asserts what happens to the users the rule is not targeting. On the functional side, UsersGroupsRightsManagementIT#allowGroupRightsAtPageLevelWhenUserRightDeniedAtWikiLevel denies the edit right to a user at wiki level, not at page level.
Added the test at the authorization-engine level rather than as a functional test, as was done for XWIKI-24701. The expected result of the manual test — "the user is not allowed to edit that page" — is pure authorization semantics, and the engine level lets the three assertions the manual test implies but doesn't state all be covered in a few milliseconds instead of a few minutes of browser time: the edit right is gone on that document, the user's other rights (view, comment) survive, and a user the rule is not targeting keeps the edit right. The rights-editor UI path the manual test describes is already exercised by UsersGroupsRightsManagementIT.
Test added: DefaultAuthorizationManagerIntegrationTest#userDenyEditAtDocumentLevel, with a new testwikis/userDenyEditAtDocumentLevel.xml fixture — a wiki without any rule, and a document carrying a single denyUser type="edit" rule for userA. The contrast with userB, which keeps the edit right on that same document, is what keeps the assertion from being vacuous.
