feat(audit): Batch 23 — settings key renames with migration (CC1) + config.ts (CC11)

CC1: customCommandEnabled→enableCustomCommands, downloadArchive→
useDownloadArchive, clipboardWatch→watchClipboard, sidebarCollapsed→
isSidebarCollapsed, hardwareAcceleration→useHardwareAcceleration,
videoDir/audioDir→videoFolder/audioFolder (+ chooseDir/clearDir store
actions → chooseFolder/clearFolder). Rename map in settingsMigration.ts
(pure, unit-tested incl. pre-rename backup fixture), applied as an
idempotent on-disk shim at store open and on backup import so old
settings.json and old backups both keep working.

CC11: update host/owner/repo + release API moved to src/main/config.ts.

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

src/main/settingsMigration.ts

@@ -0,0 +1,40 @@
+/**
+ * Settings key renames (CC1): boolean keys follow the is/has/should/<verb>
+ * convention and folder keys say "folder" (matching the UI) instead of "dir".
+ * The rename is a breaking on-disk change for `settings.json`, so it ships with
+ * this migration, applied in two places:
+ *
+ *   - the electron-store shim in settings.ts, which moves any old key found on
+ *     disk to its new name once (idempotent — the old key is deleted after);
+ *   - backup import (backup.ts), so a backup exported by an older AeroFetch
+ *     still restores cleanly.
+ *
+ * Pure and unit-tested (test/settingsMigration.test.ts). New settings keys must
+ * follow the convention up front — this list should only ever grow when a key
+ * is deliberately renamed.
+ */
+export const RENAMED_SETTINGS_KEYS: ReadonlyArray<readonly [string, string]> = [
+  ['customCommandEnabled', 'enableCustomCommands'],
+  ['downloadArchive', 'useDownloadArchive'],
+  ['clipboardWatch', 'watchClipboard'],
+  ['sidebarCollapsed', 'isSidebarCollapsed'],
+  ['hardwareAcceleration', 'useHardwareAcceleration'],
+  ['videoDir', 'videoFolder'],
+  ['audioDir', 'audioFolder']
+]
+
+/**
+ * Return a copy of `obj` with every legacy key moved to its new name. A value
+ * already present under the NEW name wins (the old key is simply dropped), so
+ * a half-migrated or hand-merged file can't regress a newer value.
+ */
+export function migrateSettingsKeys(obj: Record<string, unknown>): Record<string, unknown> {
+  const out: Record<string, unknown> = { ...obj }
+  for (const [oldKey, newKey] of RENAMED_SETTINGS_KEYS) {
+    if (oldKey in out) {
+      if (!(newKey in out)) out[newKey] = out[oldKey]
+      delete out[oldKey]
+    }
+  }
+  return out
+}