feat(collaboration): support mobileView and mobileEdit WOPI actions

[LetsDrinkSomeTea]

[!WARNING] Disclaimer
This PR was written by AI, I'm not familiar with collaboration/wopi, but i thought maybe this would be a better start than a simple feature request. If feedback is provided I will manually make the necassary changes from now on.

Description

The collaboration service ignored the mobileView and mobileEdit actions from the
/hosting/discovery endpoint of OnlyOffice compatible document servers (OnlyOffice,
Euro-Office). Mobile users were therefore always served the desktop editor.

Collabora is not affected: it serves one URL per file type and adapts its UI to the browser
user agent on its own. OnlyOffice compatible servers instead provide separate action URLs and
leave the choice to the WOPI host.

Changes

• parseWopiDiscovery() now also stores the mobileView and mobileEdit actions. The rest of
  the processing (malformed query parameter cleanup, storage layout) is unchanged.
• getAppUrl() takes a context.Context and, for non-Collabora apps, prefers
  mobileEdit for read/write and mobileView for read-only requests coming from a mobile
  browser. Mobile detection uses ctxpkg.ContextGetUserAgent() from reva, no custom UA parsing.
• New setting COLLABORATION_WOPI_ENABLE_MOBILE (default enabled, this fixes broken
  behaviour rather than adding something new). Documented as applying to OnlyOffice compatible
  backends only.

Fallback behaviour

Falling back is mandatory, not best effort. A user must never get an empty URL or an error
where the desktop editor worked before:

• Mobile action missing in the discovery (OnlyOffice Community Edition often ships no
  mobileEdit) → previous desktop URL.
• A read/write request with no mobileEdit falls back to the desktop edit URL, never to
  mobileView — otherwise a user with write permission would silently be downgraded to a viewer.
• No user agent in the context (the normal case for non browser clients) → desktop path, without
  log noise.
• Collabora branch untouched, pinned by tests.

Known limitation

iPadOS Safari identifies itself as desktop macOS and is therefore not detected as mobile. Not
addressed here.

Testing

Unit tests (Ginkgo/Gomega, existing setup):

• pkg/helpers/discovery_test.go — discovery fixture extended with mobileView/mobileEdit,
  covering parsing and retrieval via GetAppURLFor.
• pkg/service/grpc/v0/service_test.go — matrix of mobile/tablet/desktop UA × VIEW_MODE_READ_ONLY
  and VIEW_MODE_READ_WRITE, plus the fallback cases (mobile action missing, no UA in context,
  feature disabled) and two Collabora cases pinning the unchanged behaviour.

Verified manually against a running OpenCloud with a stub OnlyOffice discovery endpoint
(POST /app/open, only the User-Agent header varied):

view_mode	User-Agent	resulting app URL
write	Android Chrome	…/word/mobileedit
write	Desktop Chrome	…/word/edit
read	Android Chrome	…/word/mobileview
read	Desktop Chrome	…/word/view
write	Android Chrome, COLLABORATION_WOPI_ENABLE_MOBILE=false	…/word/edit
read	Android Chrome, COLLABORATION_WOPI_ENABLE_MOBILE=false	…/word/view

make ci-golangci-lint reports no new findings for the changed files.

#3167

[codacy-production]

Up to standards ✅

🟢 Issues 0 issues

Results:
0 new issues

View in Codacy

🟢 Metrics 13 duplication

Metric	Results
Duplication	13

View in Codacy

_{NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.}