Remove remaining backup_type dependencies and reject legacy configuration imports

[borg-codex-bot]

Problem and relationship to #486

#486 introduces permanent job UUIDs while preserving existing application behavior. Its implementation in #494 still uses backup_type / type_id for type-specific defaults, automatic icons, legacy configuration imports, and fallback keys for unresolved historical records.

The maintainer explicitly approved implementing and testing this follow-up together with #486 in the existing branch codex/issue-486-job-ids and PR #494. Do not resume the frozen #447 implementation or add work outside the scope below. Stable promotion still requires explicit maintainer approval.

Agreed scope

1. Store effective settings directly in each job

• Use the job's explicit compression and retention values in the Wizard and backup runner. Remove runtime lookups based on COMPRESSION_<TYPE> and RETENTION_<TYPE>_*.
• Before removing these dependencies, fill missing values in existing jobs once from the settings that are currently effective. Preserve explicit values and existing behavior. Apply the repository's idempotent, audited migration requirements.
• New jobs receive the existing Wizard defaults and save them explicitly: lz4, 7 daily, 4 weekly, 6 monthly, and 3 yearly retention values.
• Validate required settings explicitly. Do not require backup_type / type_id to load, edit, or run a supported job, and do not silently derive missing settings from its name or archive prefix.
• Keep the existing cache and check-marker references. This task does not change retention semantics or introduce new global settings.

2. Use a fixed default icon

• Use the existing archive icon when no icon is selected. Remove automatic icon/type presentation dependencies on backup_type.
• For existing jobs, first persist their currently effective automatic icon and color so the transition does not change their appearance. Preserve explicit selections.
• Do not infer an icon or color from the job name, UUID, location, or archive prefix. New jobs with no explicit color use the normal neutral appearance.

3. Reject unsupported old configuration packages

• Stop automatically converting configuration/job export packages in the old job format during import. The maintainer also explicitly requested rejecting old profile exports, even when their profile content might otherwise be compatible.
• Supported inner formats: bbui-job-bundle-v3, bbui-job-bundle-secure-v3, and bbui-profile-secrets-v2; jobs require schema 5, a valid UUID, an explicit archive prefix and complete settings. Keep the authenticated encryption envelope unchanged.
• Validate the supported package/job schema and required fields, including UUIDs, before any persistent write. Do not judge compatibility solely by the export date.
• Reject an unsupported package with a clear, localized error. An unsuccessful import must leave jobs, schedules, repository/storage inventories, settings, and secrets unchanged.
• The supported one-time upgrade migration of an existing installation remains available. After that migration, the user must create a fresh configuration export.
• Preserve the existing explicit import modes for supported packages; rejecting old formats must not silently change overwrite or copy semantics for supported imports.

Suggested English import error:

This configuration package uses a format that is no longer supported. The import was aborted and no changes were made. Update and migrate the source installation, then create a new configuration export.

This compatibility restriction concerns plugin job and profile configuration exports. Existing Borg backup archives remain usable for restoring data and do not need to be recreated.

4. Treat unassignable historical files as orphans

• Historical files without a usable UUID or without a matching existing job are orphaned records. Do not assign them to another job, reconstruct ownership from type/location/name, or invent a replacement UUID.
• Remove synthetic job identities such as legacy:flash_local from normal job handling.
• Do not include orphaned records in current job-specific calculations or associations.
• Preserve the orphaned files. Automatic deletion, reassignment tools, and an orphan-cleanup UI are outside this issue; cleanup can be a separate future feature.
• Active jobs and newly generated run data require a valid UUID. A missing UUID in new data is an error, not a legacy compatibility case.

5. Use archive size and file counts for restore probes

• Remove RESTORE_TEST_FORCE_CHUNK_TYPES and its settings input. Do not introduce a per-job chunk option or persist the former type-based decision.
• Use the existing configured archive-size threshold alone (500 GB by default; 0 disables switching). Below the threshold, use the full archive dry-run; at or above it, use the chunked file sample. Removing the former photos/vms rule deliberately changes smaller archives of those types to full dry-runs.
• Count regular files for the sample and coverage; directories must not consume the 1,000-file limit or count as verified files. The maintainer explicitly requested this correction.
• Aim for the configured coverage (5% by default), capped by the configured file limits (1,000 by default). Select across regular archive files and execute groups using the existing chunk-size setting.
• Report achieved file coverage: 10,000 files -> 500 sampled files -> 5%; 100,000 files -> 1,000 sampled files -> 1%. Keep the independent level 3 sample size.
• Test size-boundary behavior, many directory entries, file caps and the absence of type-dependent selection.

Publication and documentation requirement

This change requires a user-visible release-note fragment, updated import guidance, and an explicit notice in both German and English when the version is published, including the forum announcement. Do not rely only on the import error.

Suggested English publication notice:

Important: Create a new configuration backup. Job and profile configuration backups in the previous data format can no longer be imported starting with this version. After updating and successfully completing the migration, create new job and profile configuration backups. Existing Borg backup archives remain usable for restoring data.

Acceptance checks

• Existing explicit job settings remain unchanged; missing values are materialized from the previous effective configuration. Repeating the migration makes no additional changes, and failure is reported without silently discarding data.
• Supported jobs load, edit, save, and run without backup_type / type_id. Changing name or archive prefix does not change the effective saved settings.
• Existing automatic and explicit icons/colors retain their appearance. A new job without an icon selection uses archive.
• An old-format import is rejected during preview and execution before any write; supported exports remain importable through their existing modes.
• Unassignable history remains on disk, receives no replacement identity, and is excluded from current job-specific associations and calculations. No cleanup runs automatically.
• New run/status data always carries the correct UUID; missing UUIDs are reported as errors.
• German and English import messages and publication notices explicitly distinguish configuration backups from Borg archives.

Initial code references

Reviewed on the #486 branch at 7857674398164cf932a46c370a4ddc10dd4ed5aa:

• api/wizard_api.py and api/wizard_runner.py: type-specific defaults and required backup_type.
• ui/js/pages/jobs.js and ui/js/pages/wizard.js: automatic icon/type presentation.
• api/settings_transfer_api.py: old-format import conversion.
• api/migrations/job_ids_v1.py: one-time migration and unresolved historical ownership.
• runtime/lib/status.py, api/reports_api.py, and related readers: legacy: fallback identities.

Keep job_id / job_key naming, the UUID ownership model, Dashboard layout, Borg archive handling, and native prune behavior outside this follow-up's scope unless a change is strictly necessary for the agreed requirements. Ask the maintainer before adding other work.