Delete asks for confirmation, not a password

[mastacontrola]

Problem

An account that an OIDC provider creates has no local password. With FOG_REAUTH_ON_DELETE on (the default), every bulk delete asks for the account password, so that account can never delete anything. Reported at https://forums.fogproject.org/topic/18239 (problem 2 of 2; problem 1 was #1749).

Cause

The prompt was meant to confirm that somebody really wanted to delete many items. A password proves who is at the keyboard, not what they meant. The control was also partial: the host edit-page delete never asked (FOGPage::delete()), and no REST API route called checkauth().

Change

• Remove FOGBase::checkauth() and its six callers: FOGPage::deletemulti, the pending host and pending MAC deletes in HostManagement, and delete/deletemulti in RoleManagement and UserGroupManagement.
• Remove the password field from every delete dialog: the shared list dialog, the two pending-host dialogs, and both API token dialogs. The dialog title is "Confirm delete", the body says "This cannot be undone.", and the button still names the count.
• $.deleteSelected always opens the dialog before it posts, and posts no fogguipass. The 401 re-prompt is gone. $.reAuth is now $.confirmDelete, and $.finishReAuth is now $.finishConfirmDelete.
• Schema step 437 deletes FOG_REAUTH_ON_DELETE and FOG_REAUTH_ON_EXPORT. No code read the export setting. FOG_SCHEMA is 437 and FOG_BCACHE_VER is 367.

Behavior changes

• An install with FOG_REAUTH_ON_DELETE off now gets a confirm dialog on bulk delete. Before, the delete ran on the first click.
• The role and user group edit-page delete works with the old default. It sent no password, so it answered 401 whenever the setting was on.
• The two settings disappear from FOG Configuration.

No fog-plugins change: no plugin uses the delete password path.

Verification

• tests/delete-confirms-without-password.test.php: 17 of 19 checks fail on the base, and 19 of 19 pass with the change.
• tests/apitoken-grid-and-scope.test.php is updated for the rename and passes.
• All 284 PHP test files pass locally, and both phpstan passes report no errors.
• Live check against the lab database. The fix ran from a shadow tree with FOG_SCHEMA held at 436 in that copy, so nothing migrated. FOG_REAUTH_ON_DELETE is on in the lab.

Case	Deployed base	This PR
Host deletemulti, no password posted	401, Invalid Login	200, Delete Success
Role edit-page delete, no password posted	401, Invalid Login	200, deleted
Delete dialogs (host list, pending hosts, API tokens, roles, user groups, user token card)	password field	"Confirm delete", no password field

The browser click-through was not run. The request checks above cover what it would show.

🤖 Generated with Claude Code

https://claude.ai/code/session_014kd8mRPpMPXsCgXwhH4Xzu