Phase 8/9: Cut over import, configuration recovery, deletion, and identity diagnostics

[borg-codex-bot]

Parent: #447

Depends on: Phase 7/9

Delivery branch: codex/issue-447-immutable-job-ids

Delivery model: This phase is committed to the shared #447 integration branch and the single draft pull request against main. It is not merged or released independently.

Objective

Complete the job identity cutover for configuration transfer, backup/restore, duplication, deletion, support diagnostics and system health. Every persistent ID relationship must have a defined lifecycle before the migration is activated.

Import, export, and duplication

Implement the identity rules from #447:

• importing as a new job always generates a new ID;
• duplicating a job always generates a new ID;
• merging into an explicitly selected existing job retains the target ID;
• a same-installation full configuration restore preserves valid IDs;
• cross-installation full restore preserves IDs only without collisions or after an explicit remap plan;
• jobs are never merged merely because names, prefixes, repositories or legacy keys match;
• bundles include and validate an ID reference map for selected dependent objects.

All dependent records included in a transfer must be remapped consistently or rejected before writes.

Configuration backup and recovery

• Include every new ID-based store and association in settings backup.
• Validate referential integrity before replacing active configuration.
• Define collision and partial-bundle behavior.
• Preserve migration snapshots separately from normal configuration exports.
• Document that restoring configuration does not downgrade plugin code.
• Ensure secrets keep their existing protected handling.

Deletion and factory reset

• Delete only active artifacts that explicitly reference the selected job_id.
• Never delete by broad mutable filename or prefix matching.
• Preserve historical artifacts unless the user confirms their specific deletion.
• Define managed-file ownership needed by dependent features such as Support managed per-job Borg exclusion pattern files with --exclude-from #470.
• Include all new stores in the existing guarded factory-reset workflow.
• Keep repository deletion safety unchanged.

Diagnostics and support bundles

• Report duplicate IDs, missing IDs, dangling active references and unresolved legacy records.
• Show migration status and actionable failures under System Health and Migration.
• Include bounded friendly descriptors and IDs in support data without secrets.
• Avoid dumping full sensitive configuration or imported exclusion rule contents.
• Detect orphaned ID-owned files and distinguish safe cleanup candidates from preserved history.

Compatibility cleanup

• Inventory every remaining use of job_key, backup_type or location as identity.
• Keep only explicitly documented boundary readers for legacy request resolution and historical parsing.
• Remove accidental dual writes and fallback joins.
• New jobs and newly written dependent data must be ID-only.

Tests

• new import, explicit merge, duplicate, same-installation restore and cross-installation collision behavior;
• complete reference-map remapping;
• transaction rollback on invalid or partial bundles;
• precise ID-owned deletion and confirmation behavior;
• factory reset coverage;
• support bundle secret checks;
• health findings for duplicate, missing, dangling and orphaned states;
• static or focused checks proving no undocumented mutable active identity remains.

Test-channel policy

Do not publish a test-channel version yet. This phase completes the implementation surface, but the migration is still intentionally inactive until the final end-to-end qualification in Phase 9.

Acceptance criteria

• Transfer and recovery operations preserve or remap IDs according to explicit rules.
• Deletion cannot target unrelated artifacts through mutable-name matching.
• Health and support diagnostics expose every identity-integrity problem safely.
• No undocumented active writer persists mutable job identity.
• The full application is ready for migration activation testing.