feat(updater): clear app_install_overwrite on major upgrades

[ernolf]

• Resolves: Consider clearing app_install_overwrite (or warning about it when detected) for major version upgrades #43026

Summary

app_install_overwrite records that an admin force-enabled an app despite its max-version. That statement is bound to the major version it was made on — it says the app was tried on 33, not that it will work on 34. Today the list survives the upgrade, so on the next major every entry silently re-enables an app that was never checked against the new release. Nothing ever removes an entry, so the list only grows; instances that have been upgraded a few times carry dozens of them.

This clears the value when the upgrade crosses a major boundary. Apps that are genuinely incompatible then stay disabled, and the admin re-grants the overwrite per app, deliberately, on the version it now applies to.

From the support forum: admins regularly do not know what the setting does, collect entries in it over years, and find out what it was for when an upgrade takes the instance down.

What changes

• Updater::doUpgrade() deletes app_install_overwrite right after the "upgrade possible" check, before anything else runs. Not a major upgrade, not touched.
• New private helper Updater::isMajorUpgrade(), tested in tests/lib/UpdaterTest.php.
• core/Command/Upgrade.php and core/Controller/UpdateController.php read the overwrites inside the incompatibleAppDisabled listener instead of copying them into a variable before the upgrade starts. Without this the deletion would take effect but the stale copy would keep suppressing "Disabled incompatible app: …" — the admin would get apps disabled and no word about which ones. The two changes only make sense together.
• The third reader, lib/OC.php, renders the "update needed" page before the upgrade starts and reads the value per request. It is unaffected and left alone.

Behaviour

	before	after
minor / patch upgrade	overwrites kept	overwrites kept
major upgrade, app has a compatible version	re-enabled	re-enabled (the version fits, no overwrite needed)
major upgrade, app still incompatible	silently re-enabled, no message	stays disabled, reported as incompatible

Prior art

Two setup projects already do this outside the server, because the server does not.

Nextcloud AIO deletes the value when the image crosses one major, in its container entrypoint. It has been there since the initial import, so there is no PR to point at.

The Nextcloud VM scripts do the same, added in nextcloud/vm#1835 after nextcloud/vm#1834 and moved to its current place in nextcloud/vm#1848. Same major comparison:

# Prevent apps from breaking the update due to incompatibility
# Fixes errors like https://github.com/nextcloud/vm/issues/1834
# Needs to be executed before backing up the config directory
if [ "${CURRENTVERSION%%.*}" -lt "${NCVERSION%%.*}" ]
then
    print_text_in_color "$ICyan" "Deleting 'app_install_overwrite array' to prevent app breakage..."
    nextcloud_occ config:system:delete app_install_overwrite
fi

Both sit in front of the same occ upgrade and work around the same gap, and neither helps anyone who installs another way. If this lands, both can drop their own handling.

Note for admins

Admins who rely on force-enabled apps have to re-force them after a major upgrade. That is the intended cost, and it is the same action they took the first time.

Checklist

• Code is properly formatted
• Sign-off message is added to all commits
• Tests (unit, integration, api and/or acceptance) are included
• Screenshots before/after for front-end changes
• Documentation (manuals or wiki) has been updated or is not required
• Backports requested where applicable (ex: critical bugfixes)
• Labels added where applicable (ex: bug/enhancement, 3. to review, feature component)
• Milestone added for target branch/version (ex: 32.x for stable32)

AI (if applicable)

• The content of this PR was partly or fully generated using AI
  Assisted-by: ClaudeCode:claude-opus-5