fix: require explicit confirmation for destructive operations

[codebydaksh]

fix: require explicit confirmation for destructive operations

Summary

This PR fixes a security vulnerability in elicit_or_fallback() where destructive
Okta operations could execute without user confirmation when the MCP client does not
support the elicitation protocol.

Vulnerability

File: src/okta_mcp_server/utils/elicitation.py
Function: elicit_or_fallback()

The function accepted an auto_confirm_on_fallback=True parameter that, when set,
would return confirmed=True whenever elicitation was unavailable (unsupported client,
McpError, or any other exception). This effectively bypassed the confirmation
requirement for all destructive operations that used this flag.

Affected operations (8 total)

Tool	File	Operation
deactivate_user	users.py	Deactivate an Okta user
delete_deactivated_user	users.py	Permanently delete a user
deactivate_application	applications.py	Deactivate an application
deactivate_lifecycle_policy	policies.py	Deactivate a lifecycle policy
delete_lifecycle_policy	policies.py	Delete a lifecycle policy
deactivate_access_policy	policies.py	Deactivate an access policy
delete_access_policy	policies.py	Delete an access policy
delete_device_assurance	device_assurance.py	Delete a device assurance policy

Attack scenario

An MCP client that does not support elicitation (or one that throws an exception
during the elicitation call) would cause every destructive operation above to proceed
immediately without any user confirmation. This violates the principle of least
privilege and could lead to accidental or malicious deletion of users, applications,
and policies.

Fix

When elicitation is not supported or throws an exception, the fallback now
always returns confirmed=False, requiring the caller to use the legacy
two-tool confirmation flow. The auto_confirm_on_fallback parameter is retained
for API compatibility but is now ignored and marked as deprecated.

Changes

• src/okta_mcp_server/utils/elicitation.py: Removed three code paths that
  returned confirmed=True when auto_confirm_on_fallback=True. Updated docstring
  to document the new behavior and deprecate the parameter.

CWE References

• CWE-862: Missing Authorization -- The original code skipped the authorization
  (confirmation) step when elicitation was unavailable, allowing destructive
  operations without the required user consent.
• CWE-306: Missing Authentication for Critical Function -- Destructive operations
  that require explicit user confirmation could proceed without any authentication
  of user intent when the elicitation protocol was not available.

Test plan

1. Verify that with an elicitation-capable client, the confirmation dialog is shown
   and the operation only proceeds when the user clicks "Confirm".
2. Verify that with a client that does NOT support elicitation, the fallback returns
   confirmed=False and a confirmation_required payload.
3. Verify that when the elicitation call throws an exception, the fallback returns
   confirmed=False.
4. Run the existing elicitation test suite to ensure no regressions:
   pytest tests/elicitation/