Automatically migrate supported legacy configuration on application startup

[Staphylococcus]

Parent: #23

Milestone: v1.9.0. Related: #20, #21, #55, #87.

Outcome

Whenever a migration-supporting LG Buddy version starts with supported legacy configuration, automatically convert it before normal config-dependent work. Recognize the actual saved contents on every startup; do not depend on the installer, a previous-version comparison, or a one-time completion marker. Current configuration is a no-op.

There is no migration screen, acknowledgement, command, --yes requirement, or Configuration step in onboarding. The existing setup flow continues to own pairing and installation/repair when those are actually needed. Setup-attention notifications are a separate future deliverable, #267, outside v1.9.0 and outside this parent's completion criteria.

Migration contract

• Reuse raw recognition, aliases, validation and targeted config editing. For a saved TV profile, convert missing/explicit bscpylgtv platform to lg_webos; convert retired swayidle backend to auto. Preserve TV identity, enabled/disabled monitoring preferences, unrelated settings, comments and unknown keys. No silent disabling or enabling.
• Distinguish a fresh absent/empty/settings-only configuration from a real saved legacy profile. Do not create a TV profile, hide invalid/partial data, or guess unsupported conversions.
• Conversion is local configuration work. It must not connect to the TV, pair, prompt on the TV, probe GNOME/Wayland, change credentials, install dependencies, activate services, or depend on a live desktop/network. An offline TV or unavailable idle source cannot prevent valid config conversion.
• Publish one validated config atomically under the existing cooperating-writer lock, with ownership/path protections and source revalidation. Never overwrite an external edit or expose a partial combined conversion. Current config is not evidence of pairing or runtime readiness.
• Reload after conversion, then follow existing runtime and setup checks. Missing native credentials remain an ordinary pairing requirement; unavailable monitoring remains a feature/runtime condition. Conversion neither satisfies these checks nor rolls back when they fail later.
• Cover GUI, CLI (including setup/noninteractive commands), and background/service starts that consume application config. Help/version, explicit read-only diagnostic paths, and internal protocol probes keep their no-config-mutation contract; do not bury writes inside general read-only getters. No installer/root-scriptlet migration or new elevation path.
• Failure leaves config intact before publication and reports the concrete storage/validation problem through existing error handling. Do not ask the user to acknowledge or manually run migration. Interrupted or repeated starts remain safe and idempotent.

Reuse and changed policy

#256 and #257 remain delivered foundations. Reuse their raw detection and publication/concurrency safeguards. The old #257 policy requiring acknowledgement, TV verification and desktop readiness before config publication is superseded for automatic conversion. Do not merely auto-acknowledge that interactive executor or pretend a credential exists to satisfy its commit preconditions.

Delivery

• Detect stale 1.x configuration and gate startup and services #256 — raw detection and config-consumer protection.
• Implement the v2 migration commit path: pairing, atomic write, and failure semantics #257 — migration planning and safe publication foundations.
• Implement automatic local configuration conversion for startup #265 — local automatic conversion and config-only publication.
• Run automatic migration at GUI, CLI and service startup and verify installed upgrades #258 — GUI/CLI/service startup integration and installed-upgrade evidence.

Remaining: #258 — startup wiring + release-bundle evidence. Keep this parent open until #258 is accepted.

Acceptance

• Every supported config-using startup handles supported stale contents automatically; current contents cause no rewrite and newly supplied legacy contents are recognized on a later start.
• Combined conversion preserves preferences/identity and succeeds without TV, native idle capability, credentials, or user acknowledgement.
• Concurrent starts, external edits, ownership/path refusals and interrupted writes preserve data; credentials are untouched.
• Fresh setup and existing pairing/service/integration flows still work; conversion cannot bypass runtime readiness checks.
• Installed GUI, CLI and service entrypoints plus existing Ubuntu/APT, Fedora/DNF and Arch release-bundle lanes verify the contract.

No migration UI or setup-attention delivery in v1.9.0. No new schema/dependency, credential import/deletion, system package removal, or new package artifacts (#134/#135/#136). Legacy implementation removal remains #55/#87.

[Staphylococcus]

Decomposed into three sequential slices (this v1.9.0 window):

• Detect stale 1.x configuration and gate startup and services #256 Detect stale 1.x configuration and gate startup and services
• Implement the v2 migration commit path: pairing, atomic write, and failure semantics #257 Implement the v2 migration commit path: pairing, atomic write, and failure semantics (blocked by Detect stale 1.x configuration and gate startup and services #256)
• Run automatic migration at GUI, CLI and service startup and verify installed upgrades #258 Present the v2 migration flow in the GUI and extend release-bundle smoke (blocked by Implement the v2 migration commit path: pairing, atomic write, and failure semantics #257)

Tests ship with each slice using the existing cucumber/lib-test, GUI-journey, and release-bundle smoke harnesses — no separate test workstream.