[Bug]: Nextcloud iOS app falls back to native file download instead of Collabora editor (regression after #5838)

Describe the bug
After the fix in PR #5838 (merged Jul 9, 2026), the previous 404 on the directEditing token redemption endpoint is resolved. However, a different, subsequent issue remains: the Nextcloud iOS app does not attempt to use the Collabora editor at all — it falls back to a native iOS share sheet ("Copy to Numbers") instead of opening the document for editing.

Opening the same document via mobile Safari works perfectly. The issue is specific to the Nextcloud iOS app.

To Reproduce

1. Set up Nextcloud Office with a self-hosted Collabora server (connection test passes, occ richdocuments:activate-config passes all checks)
2. Open the Nextcloud iOS app
3. Navigate to a .xlsx or .docx file
4. Tap the file to open it

Expected behavior
The Nextcloud iOS app opens the document in the Collabora editor (as it does in the mobile browser).

Screenshots
N/A

Client details:

• OS: iOS 26.5.2
• Browser: Nextcloud iOS app (not browser-based)
• Version: Nextcloud iOS app 34.1.0
• Device: iPhone

Server details

Operating system: Unraid (Linux), Docker-based

Web server: Apache (mod_php)

Database: MariaDB

PHP version: 8.3

Nextcloud version: 34.0.2

Version of the richdocuments app: 11.1.0 (includes fix from PR #5838)

Version of Collabora Online: CODE 26.04.2.4 (self-hosted, external Docker container, nginx reverse proxy)

Configuration of the richdocuments app

{
    "apps": {
        "richdocuments": {
            "canonical_webroot": "",
            "disable_certificate_verification": "",
            "doc_format": "ooxml",
            "enabled": "yes",
            "external_apps": "",
            "installed_version": "11.1.0",
            "public_wopi_url": "https://office.mydomain.at",
            "types": "filesystem,prevent_group_restriction",
            "wopi_allowlist": "10.0.0.0/8,172.16.0.0/12,192.168.0.0/16",
            "wopi_url": "https://office.mydomain.at"
        }
    }
}

GET /ocs/v2.php/apps/files/api/v1/directEditing → 200 OK

POST /apps/richdocuments/token → 200
GET /index.php/apps/richdocuments/wopi/files/{id} → 200 (COOLWSD Agent)
GET /index.php/apps/richdocuments/wopi/files/{id}/contents → 200 (COOLWSD Agent)
POST /index.php/apps/richdocuments/wopi/files/{id} → 200 (COOLWSD Agent)

✓ Reset callback url autodetect
Checking configuration
🛈 Configured WOPI URL: https://office.mydomain.at
🛈 Configured public WOPI URL: https://office.mydomain.at
🛈 Configured callback URL:
✓ Fetched /hosting/discovery endpoint
✓ Valid mimetype response
✓ Valid capabilities entry
✓ Fetched /hosting/capabilities endpoint
✓ Detected WOPI server: Collabora Online Development Edition 26.04.2.4

Additional context

This is not the same issue as #5758 / PR #5838, which fixed a 404 on the token redemption endpoint (/apps/files/directEditing/{token}). In this case, the iOS app fetches directEditing capabilities successfully but then does not initiate the Collabora flow at all — POST /apps/richdocuments/token is never called.

Server-side configuration is confirmed correct. The issue appears to be on the iOS app side: it receives the directEditing capabilities response but does not act on them to open the document via Collabora.

Start with the iOS app handling of GET /ocs/v2.php/apps/files/api/v1/directEditing and compare it with the Safari flow. Check why the app does not follow with POST /apps/richdocuments/token; done means opening the .xlsx or .docx file in Collabora rather than the native share sheet.