Potential fix for code scanning alert no. 3: Clear-text logging of sensitive information

[garland3]

Potential fix for https://github.com/sandialabs/VISTA/security/code-scanning/3

To fix this problem, we must ensure that no sensitive data or untrusted user-supplied content is logged in clear text. That means:

• When logging database operations regarding API keys, never include the API key value, the hash, or any untrusted fields such as the key name verbatim without review.
• Only include minimal, non-sensitive and non-identifying fields, such as resource IDs or static information, in log records.
• For the create_api_key and deactivate_api_key operations, sanitize or eliminate logging of user-supplied fields in additional_info (e.g., do not log api_key.name). Log only safe, pre-reviewed constants such as the user ID (which is already a UUID and not PII), and the fact an operation occurred.

Required changes:

• In crud.create_api_key: update the call to log_db_operation to not include the user-supplied API key name. Log only the user_id (already a UUID), or remove additional_info entirely.
• In crud.deactivate_api_key: the call to log_db_operation only logs { "deactivated": True }, which is fine.
• In log_db_operation: optionally, add a security comment to indicate that additional_info must never include sensitive/user-supplied values; validate or sanitize as an extra layer if desired.

No new methods or imports are needed; the change is limited to the removal/editing of logging of untrusted content.

---

Suggested fixes powered by Copilot Autofix. Review carefully before merging.

[Copilot]

Pull request overview

This PR addresses a security vulnerability (code scanning alert #3) related to clear-text logging of sensitive information. The changes prevent logging of user-supplied API key names and other potentially sensitive data in database operation logs.

Key Changes:

• Added security documentation to log_db_operation function warning against logging sensitive or user-supplied data
• Removed API key name from logging in create_api_key function, retaining only the non-sensitive user_id UUID