Quiet boot migration: leave quiet alone when the user already customized the boot menu

[tritondm]

Related: #16367, #16369

#16367 reported that migration 1791898365 hides the Limine menu on dual-boot machines, and #16369 addressed it by documenting "press any key during the timeout". That works for fresh setups. It leaves out one case where I think the migration itself should behave differently.

The case

The migration already treats an uncommented timeout: as the user's own choice and leaves it alone. But it adds quiet: yes unconditionally. On my machine I had deliberately set:

timeout: 5
default_entry: Windows

The longer timeout existed for one reason: to see the menu and pick Omarchy when needed. After updating 4.0.6 → 4.5.0, the migration added quiet: yes. My timeout survived, but the menu it was meant for is now invisible. The machine appears to boot straight into Windows, and Omarchy looks like it vanished after an update. I only got back in through the firmware boot menu. I never saw the dual-boot guide change, because I had set up dual boot weeks earlier.

Suggestion

Apply the same "this is the user's" logic to quiet that the migration already applies to timeout:

• only add quiet: yes when the migration also set the timeout (i.e. set_timeout is true), or
• at least skip it when default_entry is not the shipped value or a non-Omarchy top-level entry (e.g. /Windows) exists.

Both are small checks in the existing script. If adding quiet is still wanted everywhere, a printed note during the update ("press any key at boot to show the menu; set quiet: no to keep it visible") would at least make the change discoverable.

Workaround

quiet: no in /boot/limine.conf survives later updates, since the migration only checks whether a quiet: line exists.

System

Omarchy 4.5.0-3 (from 4.0.6-1), Limine 12.9.4, UEFI, Secure Boot off, Windows entry added manually to limine.conf.

greets
tritondm