feat: connect Nextcloud to an office suite; 34.0.3:2 -> 34.0.3:3

[MattDHill]

Connects Nextcloud to an office suite, via the two new packages
collabora-online-startos and
onlyoffice-docs-startos.

What it adds

• An Office Suite action — Collabora Online, ONLYOFFICE Docs, or none — with a conditional running dependency on the chosen service.
• A generated startos-office.conf and its four proxy modules, written into the container on every start, serving the document server from Nextcloud's own origin.
• An office-connectors health check, present only while a suite is selected.

The connector app itself stays user-installed, following the Talk/Coturn precedent already in this package.

Why the editor is served from Nextcloud's origin

Both document servers can only be told one browser-facing address, so any instance reachable at more than one — a LAN address and a public domain, or a .onion — would get a working editor on exactly one of them. Proxying under Nextcloud's own origin removes the choice: the editor is always served from whichever address the browser already holds. It also means neither service needs an address, a certificate or a domain of its own, and both stay off the LAN entirely.

ONLYOFFICE derives its public URLs per request from X-Forwarded-Host/-Proto/-Prefix, so a prefix and those headers are all it needs. Collabora writes an absolute origin into its WOPI discovery document, which Nextcloud caches and copies into the editor frame verbatim — so the config rewrites that origin out with mod_substitute, leaving a root-relative urlsrc the browser resolves itself. Filed upstream as nextcloud/richdocuments#6019; if it lands, the rewrite can go.

Two failures worth calling out

trusted_domains. The existing mapper excludes bridge addresses. A document server fetches and saves over the bridge, so without the bridge IP every one of those requests comes back {"error": "Trusted domain error.", "code": 15} — the editor opens and then fails to load the document. Nothing on the Collabora side catches this: richdocuments:activate-config passes all four of its checks, because it only exercises discovery and capabilities, never the callback leg.

A second office connector. richdocuments drops the Microsoft formats out of its default-open capability whenever it finds onlyoffice or officeonline enabled (CapabilitiesService::hasOtherOOXMLApps), and the rival does not claim them unless it is configured too. Word, Excel and PowerPoint then open in neither and silently download, with nothing in Nextcloud saying why. Hence a failing health check naming the app to disable, rather than a task, which can be dismissed while the breakage remains.

Verified on a dev box

• Documents open and edit in the browser on both backends, ODF and OOXML.
• richdocuments:activate-config passes discovery, mimetype, capabilities and WOPI-server checks, with an empty public URL — which is what a relative urlsrc produces.
• occ onlyoffice:documentserver --check reports the document server connected at /ds-vpath/, a real conversion round-trip that exercises the relative URL, the proxy, the JWT pairing and the download over the bridge.
• Both of Collabora's websocket URL shapes proxy — the bare /cool/ws and the encoded-slash compat form.
• Switching backends clears the previous connector's settings in both directions; the connector health check goes red naming the rival app and recovers when it is disabled.