Notifications — Add privacy-safe delivery-stage logging for new-mail notifications

Problem

When a new-mail notification is missing, current logs cannot reliably distinguish between:

• the message being excluded by notification policy;
• notification creation being queued but never completed;
• Android notifications being disabled or the account channel being blocked;
• NotificationManager.notify() failing;
• the platform API accepting the notification but Android not displaying it.

Some delivery-impacting failures are logged only at verbose level or swallowed after being caught. This makes reports such as #10890 difficult to diagnose.

Goal

Add consistent, privacy-safe stage logging to the current production new-mail notification path.

Log these stages using stable event and reason names:

1. Notification evaluation started.
2. Notification eligible or suppressed, including a reason category.
3. Notification creation scheduled.
4. Notification creation started.
5. Notification submission attempted.
6. Submission blocked, including whether it was blocked at the app, account-group, or channel level.
7. NotificationManager.notify() returned successfully.
8. Submission failed, including a safe failure category.
9. Notification creation completed or was cancelled.

Use a generated, non-identifying attempt ID, or the notification ID once assigned, to correlate events from the same attempt. Do not log account, folder, or message identifiers.

Normal stage transitions should use the project's diagnostic log level. Blocked, cancelled, and failed attempts should be logged at a level that appears in collected debug logs.

Start with the legacy new-mail path currently used by production Thunderbird and K-9 builds. Instrumenting the feature-flagged replacement architecture is out of scope.

Acceptance criteria

• Logs show whether notification evaluation, creation, and submission were reached.
• Suppressed notifications include a stable reason category.
• Logs distinguish:
  • app-wide notifications disabled;
  • parent account channel group blocked;
  • account channel missing or disabled;
  • notification creation cancelled;
  • platform submission failure;
  • platform submission completed.
• A queued creation that never starts or completes can be identified from the event sequence.
• Events belonging to one attempt can be correlated without logging account or message identity.
• Submission success is described as submitted, not displayed or delivered.
• Failures are not handled solely by a verbose log entry.
• Logs contain no email addresses, account or folder identifiers, subjects, previews, message content, credentials, tokens, file paths, URIs, or uncontrolled exception messages.

Out of scope

• User-facing error or delivery-status UI.
• Retrying or replaying missed notifications.
• Changing notification eligibility policy.
• Fixing the fire-and-forget notification lifecycle.
• Migrating production delivery to :feature:notification.
• Proving that Android displayed the notification or that the user saw it.

Related: #10890, #10098, #11017, #7554, #8712, #11059, #11259.