Unify DMARC pass/fail chart naming on "DMARC compliance" (#865)

* Unify DMARC pass/fail chart naming on "DMARC compliance"

The same metric had three names across the dashboards: the pass/fail
pie chart was "Passed DMARC" (OpenSearch, Splunk) and "DMARC Passage"
(Grafana), while the per-domain table column added in #834 was
"% DMARC Compliant". Converge on the compliance wording, which already
anchored the "Message volume and DMARC compliance by from domain"
panels in every dashboard family:

- Pie chart: "DMARC compliance" ("DMARC Compliance" in Grafana, which
  title-cases panel names; OpenSearch and Splunk use sentence case).
- Line chart: "DMARC passage over time" -> "DMARC compliance over
  time" everywhere, so the pie rename doesn't leave the same
  inconsistency one panel down.
- Splunk filter dropdown label: "Passed DMARC" -> "DMARC compliant".
- Grafana Guide panel text and docs/source/kibana.md prose updated to
  match, plus a pre-existing typo fix ("pie charts. you").

Field names, tokens, and queries (passed_dmarc / dmarc_passed) are
untouched; only human-facing titles, labels, and prose changed.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* Fix "pie charts. you" typo in the Grafana Guide panel text

The period-for-comma typo fixed in docs/source/kibana.md also existed
in the Grafana Guide panel markdown, in both duplicated copies of the
guide text (content and options.content). Caught by Copilot review on
PR #865.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* Sync the Grafana Guide panel walkthrough with the current panels

The Guide text described a three-column table layout with a from-domain
list "on the right" and directed readers to a "Message From Header"
table, but the dashboard has two table columns (Reporting Organisations
on the left; Top 2000 Message Sources by Reverse DNS on the right with
Message volume and DMARC compliance by from domain below it) and no
Message From Header table. Point the walkthrough at the real panel
titles and mention the per-domain compliance percentage the table
shows, mirroring the kibana.md walkthrough updated in #834. Both
duplicated copies of the guide markdown (content and options.content)
remain identical.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* Scope the CHANGELOG rename claim to dashboards that have the charts

The bullet said the pass/fail charts were renamed "across the ...
Grafana dashboards", but the PostgreSQL Grafana variant has no
pass/fail pie or over-time chart, so the claim quantified over a
dashboard it doesn't apply to. Name the affected dashboards explicitly
and note the PostgreSQL variant is unchanged. Caught by Copilot review
on PR #865.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

---------

Co-authored-by: Claude Fable 5 <noreply@anthropic.com>

CHANGELOG.md

@@ -13,6 +13,8 @@
 
 ### Changes
 
+- **The DMARC pass/fail pie chart and over-time chart are now named for DMARC compliance** in the OpenSearch Dashboards/Kibana and Splunk dashboards and the Elasticsearch-backed Grafana dashboard (the PostgreSQL Grafana variant has no pass/fail charts and is unchanged): "DMARC compliance" and "DMARC compliance over time" ("DMARC Compliance" / "DMARC Compliance Over Time" in Grafana, which title-cases panel names), replacing the previous mix of "Passed DMARC", "DMARC Passage", and "DMARC passage over time". This matches the existing "% DMARC Compliant" table column and the "Message volume and DMARC compliance by from domain" panels. The Splunk dashboard's pass/fail filter dropdown label was renamed to "DMARC compliant" to match.
+- **The Grafana dashboard's Guide panel walkthrough now matches the current panel layout**, directing readers to the "Top 2000 Message Sources by Reverse DNS" and "Message volume and DMARC compliance by from domain" tables and describing the compliance percentage they show, replacing stale references to a from-domain list "on the right" and a "Message From Header" table that no longer exists.
 - **`get_dmarc_reports_from_mailbox()` gained an optional keyword-only `save_callback` parameter**, invoked once per fetched batch with a `ParsingResults` dict holding only that batch's newly parsed reports, after parsing but before any of the batch's messages are deleted or moved out of `reports_folder`. Returning `False` reports the batch as unsaved: its messages stay in place for retry and the aggregate-report dedup cache is not updated for that batch, so the retry reparses those reports rather than skipping them as duplicates. Raising counts as an unsaved batch too — the same retention and `max_unsaved_retries` bookkeeping runs — and the exception is then re-raised, so a callback that fails by raising (the CLI's does, under `fail_on_output_error`) is still bounded by the retry cap even when the caller's watch loop swallows the exception, as mailsuite's IMAP and Maildir backends do. Any other return value, including `None`, commits the batch exactly as before, which is what `save_callback=None` (the default) does for every batch. As a related, strictly safer side effect of staging the dedup keys per batch, a mid-batch crash now leaves `SEEN_AGGREGATE_REPORT_IDS` unmodified for that batch instead of partially populated.
 - **`watch_inbox()`'s `callback` is now passed through as `save_callback`**, so it runs once per batch *before* that batch is archived or deleted, with only that batch's reports, rather than once afterward with the whole check's accumulated results. It may return `False` to defer a batch to the next check.
 - **A single-shot CLI run configured with both file/mbox inputs and a mailbox connection now emits output in two passes instead of one**: mailbox-derived reports are saved through the new `save_callback` before `get_dmarc_reports_from_mailbox()` returns, and file/mbox-derived reports are saved in a second pass afterward. `append_json`/`append_csv` are already append-safe and watch mode already called its callback repeatedly, so this changes how often output happens in the single-shot case, not what is written. When a mailbox connection is configured and the file/mbox inputs yielded no reports (none given, or none parsed), the second pass is skipped entirely rather than printing an empty JSON document.

dashboards/splunk/dmarc_aggregate_dashboard.xml

@@ -28,7 +28,7 @@
       <default>*</default>
     </input>
     <input type="dropdown" token="passed_dmarc" searchWhenChanged="true">
-      <label>Passed DMARC</label>
+      <label>DMARC compliant</label>
       <choice value="*">any</choice>
       <choice value="true">true</choice>
       <choice value="false">false</choice>
@@ -157,7 +157,7 @@
       </chart>
     </panel>
     <panel>
-      <title>Passed DMARC</title>
+      <title>DMARC compliance</title>
       <chart>
         <search base="base_search">
           <query>| stats sum(message_count) by passed_dmarc</query>
@@ -246,7 +246,7 @@
   </row>
   <row>
     <panel>
-      <title>DMARC passage over time</title>
+      <title>DMARC compliance over time</title>
       <chart>
         <search base="base_search">
           <query>| timechart span=1d sum(message_count) as message_count by passed_dmarc</query>

docs/source/kibana.md

@@ -38,7 +38,7 @@ valid when a message is forwarded without changing the from address, which is
 often caused by a mailbox forwarding rule. This is because DKIM signatures are
 part of the message headers, whereas SPF relies on SMTP session headers.
 
-Underneath the pie charts. you can see graphs of DMARC passage and message
+Underneath the pie charts, you can see graphs of DMARC compliance and message
 disposition over time.
 
 Under the graphs you will find the most useful data tables on the dashboard. On