Documents fail to load when Nextcloud instanceid contains an underscore (fileId format collision in parseFileId())

The WOPI fileId is used in two different formats throughout richdocuments:

1. {nodeId}_{instanceid} — used for "current file" WOPI requests (built in WopiController::getUrlSrc())
2. {nodeId}_{instanceid}_{version} — used when generating a token for a specific file version

Helper::parseFileId() distinguishes between these purely by counting _-separated segments:

$arr = explode('_', $fileId);
...
} elseif (count($arr) === 3) {
    [$fileId, $instanceId, $version] = $arr;
}

This breaks if the Nextcloud instanceid itself contains an underscore (e.g. macse_zufbWjpH). A normal "current file" fileId like 61_macse_zufbWjpH then has 3 segments and is misparsed as nodeId=61, instanceId=macse, version=zufbWjpH — the trailing part of the instanceid is mistaken for a version identifier.

This causes every "open document" request to be routed through WopiController::getFile()'s version-retrieval branch (IVersionManager::getVersionFile()), which throws OCP\Files\NotFoundException since no such version exists. Every document fails to open in Collabora Online / Nextcloud Office with "Failed to load document from storage," even though the Collabora ↔ Nextcloud connection itself is healthy.

To Reproduce

1. Use (or create) a Nextcloud instance whose instanceid contains an underscore, e.g.:

   occ config:system:set instanceid --value="macse_zufbWjpH"
   

2. Set up Nextcloud Office / richdocuments against a working Collabora Online (CODE) server (confirmed reachable, healthcheck passes).
3. Try to open any existing document (creating a brand-new file from an empty template still works, since that path doesn't go through this fileId parsing).

Expected behavior

Documents open normally regardless of whether instanceid happens to contain an underscore.

Actual behavior

message: "getFile failed: /nextcloud_admin/files_versions/Documents/Welcome to Nextcloud Hub.docx.vzufbWjpH"
exception: OCP\Files\NotFoundException
  at OC\Files\Node\Root->get(...)
  at OCA\Files_Versions\Versions\LegacyVersionsBackend->getVersionFile(...)
  at OCA\Files_Versions\Versions\VersionManager->getVersionFile(..., 'zufbWjpH')
  at OCA\Richdocuments\Controller\WopiController->getFile('61', ...)

Environment

• Nextcloud version: 33.0.5.1
• richdocuments version: 10.2.0
• Collabora Online (CODE): 26.04.1.4
• Deployment: Docker (TrueNAS SCALE Nextcloud app + standalone Collabora container)

Workaround used

Locally patched parseFileId() to recombine segments 2+ as the instanceid in the 3-segment case (since in our case the version-via-fileId path wasn't in active use), but this isn't a general fix since TokenManager::generateWopiToken() does rely on a real 3-segment {nodeId}_{instanceid}_{version} format elsewhere.

Suggested fix

Since instanceid can legitimately contain underscores, the two fileId formats are fundamentally ambiguous when split naively on _. A robust fix likely needs either:

• A non-underscore delimiter between the fixed {nodeId}_{instanceid} pair and the optional {version} suffix, or
• Looking up the actual system instanceid value via IConfig::getSystemValue('instanceid') and stripping it as a known-length suffix from $fileId, rather than blindly splitting on _ and counting segments.

Start with Helper::parseFileId() and trace the fileId construction in WopiController::getUrlSrc(), the version path in TokenManager::generateWopiToken(), and consumption in WopiController::getFile(). Compare both documented formats using an instanceid containing an underscore, while preserving version retrieval; done means current documents open and specific-file-version tokens still resolve correctly.