Add debug log guard and oversized log cleanup workflow

Summary

Add a debug log guard that detects oversized WordPress debug logs and provides safe admin actions.

Why this matters

Large debug logs can waste disk space and sometimes contribute to slow troubleshooting workflows. Site owners often discover the problem only after storage pressure or repeated errors.

Proposed scope

• Detect whether WP_DEBUG_LOG is enabled where safely possible.
• Show debug log file size and last modified time when readable.
• Warn when the file exceeds configurable thresholds.
• Provide safe actions:
  • view tail excerpt
  • download log
  • clear/truncate with confirmation
• Add guidance for disabling debug logging in production.
• Log clear/truncate actions in optimization history.

Safety requirements

• Do not expose full logs by default.
• Redact common sensitive patterns where feasible.
• Require capability checks, nonce checks, and confirmation before clearing.
• Handle unreadable or custom log paths gracefully.

Acceptance criteria

• Admin users can see log status without exposing full log content.
• Oversized logs trigger a clear warning.
• Clear/truncate action is confirmed and logged.
• Tests or runtime validation cover missing log, unreadable log, oversized log, custom path, and permission checks.

No implementation files or tests are named. Start by locating the plugin's admin settings and optimization-history entry points, then inspect how WordPress debug-log paths and permission or nonce checks are handled; done means the listed log states, safe actions, redaction, confirmations, and validation cases work without exposing full logs.