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 therefore only covered incidentally: nothing isolates it, and nothing asserts that a user which is not a member of the denied group keeps it. On the functional side, UsersGroupsRightsManagementIT#allowGroupRightsAtPageLevelWhenUserRightDeniedAtWikiLevel only allows rights to a group 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 for the group members on that document, their other rights (view, comment) survive, and a user which is not a member keeps the edit right. The rights-editor UI path the manual test describes is already exercised by UsersGroupsRightsManagementIT.
Test added: DefaultAuthorizationManagerIntegrationTest#groupDenyEditAtDocumentLevel, with a new testwikis/groupDenyEditAtDocumentLevel.xml fixture — a wiki without any rule, userA member of groupA, userB not a member, and a document carrying a single denyGroup type="edit" rule for groupA. The contrast with userB, which keeps the edit right on that same document, is what keeps the assertion from being vacuous.
