chore(playwright): Rewrite password confirmation handler to avoid race conditions

[DerDreschner]

Summary

The password confirmation handler on playwright is using a timeout on isVisible. That is deprecated and isn't being considered anymore, which lead to several issues during our playwright tests (especially under high load on our CI runners).

When that issue occurs, the following error can be seen in the playwright tests. The timeout was raised to 90 seconds here and the issue still happened, as the whole test just stuck because of the login never being done.

Notice:   1 failed
    [admin-settings] › tests/playwright/e2e/appstore/admin-settings-apps.spec.ts:159:2 › Settings: App management › Limit app usage to group 
  43 passed (11.2m)

  1) [admin-settings] › tests/playwright/e2e/appstore/admin-settings-apps.spec.ts:159:2 › Settings: App management › Limit app usage to group 

    Test timeout of 90000ms exceeded.

    Error: expect(locator).toHaveCount(expected) failed

    Locator:  locator('#app-sidebar-vue').getByRole('list', { name: 'Limited to groups' })
    Expected: 0
    Received: undefined


      206 |
      207 | 		// Verify the "Limited to groups" list is no longer visible
    > 208 | 		await expect(appstorePage.limitedToGroupsList()).toHaveCount(0)
          | 		                                                 ^
      209 | 	})
      210 | })
      211 |
        at /home/runner/actions-runner/_work/server/server/tests/playwright/e2e/appstore/admin-settings-apps.spec.ts:208:52

    Error Context: test-results/appstore-admin-settings-ap-4ce9a-nt-Limit-app-usage-to-group-admin-settings/error-context.md

Checklist

• Code is properly formatted
• Sign-off message is added to all commits
• Tests (unit, integration, api and/or acceptance) are included
• Screenshots before/after for front-end changes
• Documentation (manuals or wiki) has been updated or is not required
• Backports requested where applicable (ex: critical bugfixes)
• Labels added where applicable (ex: bug/enhancement, 3. to review, feature component)
• Milestone added for target branch/version (ex: 32.x for stable32)

AI (if applicable)

• The content of this PR was partly or fully generated using AI

[odzhychko]

Just a thought: handlePasswordConfirmation will always make a test wait even if no password confirmation is required. Tests could be setup with locations handlers to only run this code if the password dialog actually becomes visible.

In the future this might be useful, if a test:

• doesn't care for when the password confirmation appears
• but has to call handlePasswordConfirmation often because it might appear

[DerDreschner]

Just a thought: handlePasswordConfirmation will always make a test wait even if no password confirmation is required. Tests could be setup with locations handlers to only run this code if the password dialog actually becomes visible.

Yeah, that was being proposed from Claude as well and I think it should be handled that way either. But I didn't want to make such a fundamental change as it makes the "input/expect password here" being implicit instead of explicit when looking at the tests. There are good points for both ways IMHO. 😄