fix(builtin): store server_mode explicitly and derive builtin URLs server-side

[joshtrichards]

• Resolves: # (various, possibly)
• Target version: main

Summary

Fix builtin CODE setup so Nextcloud no longer guesses builtin URLs from browser context.

The old flow had two architectural problems.

1. Builtin mode and wopi_url were inferred from a browser-generated URL.

The admin UI constructed a builtin CODE proxy URL from window.location.host and used it both to detect builtin mode and to save wopi_url. That only worked when Nextcloud’s internal and public URLs happened to match. In deployments with reverse proxies, split DNS, or different internal/public addresses or ports (for example container port mappings), it could select the wrong mode or save the wrong internal URL.

2. Builtin public_wopi_url was inferred from discovery in the wrong execution context.

For standalone Collabora, deriving the public URL from /hosting/discovery is valid because server_name in coolwsd.xml makes urlsrc deterministic. Builtin CODE behaves differently: it uses ProxyPrefix, so discovery output reflects the host and scheme of the incoming request. When discovery is fetched by Nextcloud itself — during settings saves, connectivity checks, or occ commands — the returned urlsrc reflects the server-side request context, not necessarily the browser-facing URL. That makes discovery-based public URL detection unreliable for builtin mode in proxy, split-DNS, and internal/external port-mapping setups.

This change introduces an explicit server_mode config key and derives builtin internal and public URLs dynamically from IURLGenerator on every call, so no stored value is ever consulted for builtin mode

The key design point is that builtin CODE has no independent public hostname: it is always reached through Nextcloud’s public origin. So the correct builtin public URL can be derived directly from IURLGenerator without any discovery fetch, and it stays correct automatically across domain changes. This PR also adds occ richdocuments:activate-config --builtin so CLI setup follows the same server-side derivation logic.

In practice this means:

• builtin mode is identified by server_mode, not URL comparison
• builtin internal and public URLs are derived server-side
• custom/standalone setups keep using discovery-based public URL detection

What changed

• add explicit server_mode config (builtin, custom, demo)
• derive builtin internal URL and public origin from IURLGenerator
• stop treating stored builtin URLs as canonical
• skip discovery-based public_wopi_url auto-configuration for builtin mode
• add occ richdocuments:activate-config --builtin
• validate builtin CLI setup before committing config, with optional --force
• update admin settings to use server_mode directly and re-evaluate mode after async refresh
• stop constructing builtin CODE URLs in the browser
• keep legacy builtin installs working via fallback detection from stored wopi_url

Files changed

• lib/AppConfig.php

  • add SERVER_MODE
  • add builtin URL derivation helpers
  • derive builtin internal/public URLs dynamically

• lib/Service/ConnectivityService.php

  • add testUrl() for validating an explicit URL
  • make autoConfigurePublicUrl() a no-op for builtin mode

• lib/Controller/SettingsController.php

  • return server_mode and builtin_server_url
  • support builtin activation via server_mode
  • add rollback-safe builtin setup flow
  • set server_mode = 'custom' when a raw wopi_url is saved
  • honour an explicit server_mode parameter (e.g. 'demo') when one is provided

• lib/Settings/Admin.php

  • expose server_mode and builtin_server_url in initial state

• lib/Command/ActivateConfig.php

  • add --builtin and --force
  • validate builtin setup before persisting config

• src/components/AdminSettings.vue

  • use server_mode instead of URL comparison for mode selection
  • re-evaluate mode after refreshed settings
  • use explicit mode updates for demo/builtin setup
  • verify builtin browser reachability by fetching discovery directly through proxy.php

Testing

• Fresh builtin setup through admin UI works
• Builtin setup with different internal/external port-mapping setups (container environment) and/or behind reverse proxy / split internal-public URL works
• Existing builtin installs without stored server_mode are still recognized
• occ richdocuments:activate-config --builtin works with correct overwrite.cli.url
• builtin CLI setup fails clearly for internal-looking public URLs unless --force is used
• custom/standalone setup still behaves as before
• demo mode still behaves as before

Checklist

• Code is properly formatted
• Sign-off message is added to all commits
• Documentation (manuals or wiki) has been updated or is not required