docs(campaign): clarify legacy mail secret treatment

docs/CAMPAIGN_HANDBOOK.md

@@ -219,10 +219,12 @@ continue to satisfy the snapshot. A host, account identity, protocol, sender,
 or other revisioned transport change stops delivery until the campaign is
 revalidated and rebuilt.
 
-### Legacy campaign records
+### Existing legacy database records
 
-Historical versions may contain inline SMTP/IMAP material. They are retained as
-audit records, but:
+The current Campaign database may contain versions with inline SMTP/IMAP
+material. No separate historical Campaign JSON corpus exists. Inline transport
+material in those rows is treated as inert legacy data and is never interpreted
+as an executable Mail configuration:
 
 - public responses remove legacy transport fields and secrets;
 - validation, build, queue, retry, and delivery fail closed;
@@ -230,11 +232,10 @@ audit records, but:
   Mail-settings save; and
 - a locked version is preserved and must be forked to an editable successor.
 
-This is execution containment, not complete historical secret remediation.
-Operators still need a separately approved migration/retention procedure for
-old database snapshots and backups that may contain legacy campaign secrets;
-that decision and its acceptance conditions are tracked in
-[`govoplan-campaign#77`](https://git.add-ideas.de/add-ideas/govoplan-campaign/issues/77).
+Normal database backup/restore and access controls cover those rows together
+with the rest of the current database. There is no separate historical-JSON,
+backup-scanning, or inline-secret migration program. Restoring an existing
+legacy row preserves it as inert evidence and does not make it deliverable.
 
 ### Recipient and attachment evidence
 
@@ -451,9 +452,7 @@ the current baseline:
 - a fully packaged one-command Campaign reference composition with production
   policy presets and target-provider certification;
 - function-bound Postbox delivery (stage 2 of the reference program);
-- generic workflow-driven campaign transitions; and
-- complete remediation of legacy secrets in historical databases and backups
-  ([`govoplan-campaign#77`](https://git.add-ideas.de/add-ideas/govoplan-campaign/issues/77)).
+- generic workflow-driven campaign transitions.
 
 Each item needs an owning issue, implementation, failure tests, documentation,
 and release evidence before the wording above can move from planned to current.

docs/MAIL_PROFILE_BOUNDARY.md

@@ -57,10 +57,12 @@ Campaign authors need `mail:profile:use` in addition to the relevant Campaign
 permission. Profile visibility remains governed by Mail policy and campaign
 owner context.
 
-## Legacy versions and migration
+## Existing database rows and migration
 
-Older versions can contain inline SMTP/IMAP settings or credentials. GovOPlaN
-does not delete or rewrite those stored audit records automatically:
+The current database can contain campaign versions with inline SMTP/IMAP
+settings or credentials. There is no separate historical Campaign JSON corpus
+to import or remediate. GovOPlaN treats those inline fields as inert legacy
+material and does not delete or rewrite the stored audit rows automatically:
 
 - API responses omit all legacy transport fields and secrets and expose a
   `mail_profile_migration_required` marker.
@@ -72,11 +74,12 @@ does not delete or rewrite those stored audit records automatically:
 - a locked version remains unchanged. Creating its editable successor records
   the migration while retaining the locked source as audit evidence.
 
-Legacy execution snapshots are likewise retained for audit but cannot be used
-for delivery. Revalidate and rebuild an editable profile-only version. Removing
-the remaining live and backup secret copies requires the separately approved
-remediation in
-[`govoplan-campaign#77`](https://git.add-ideas.de/add-ideas/govoplan-campaign/issues/77).
+Legacy execution snapshots are likewise retained but cannot be used for
+delivery. Revalidate and rebuild an editable profile-only version. Normal
+database backup, restore, encryption, and access controls apply to the current
+database as a whole; the product does not define a separate historical-JSON or
+inline-secret recovery workflow. A restored legacy row remains inert and
+fail-closed under the same rules.
 
 ## Operator checks