[Bug] Accessibility/Screen Reader setting (UseATSupport) not persisted — no server-side write endpoint for userconfig

Describe the bug

The "Screen reader support" / "Use Assistive Technology" checkbox in Collabora Online (accessible via Help → Accessibility, or Tools → Options depending on UI mode) cannot be persistently saved. It resets to unchecked on every new document session.

Environment

• Nextcloud version: 33.0.0.16
• richdocuments version: 10.1.2
• Collabora Online (AIO): 25.04.8.3 (ghcr.io/nextcloud-releases/aio-collabora:latest)
• Deployment: Nextcloud AIO on Docker (OpenMediaVault host)
• accessibility.enable=true set via COLLABORA_ENV environment variable ✓

Steps to reproduce

1. Set accessibility.enable=true on the Collabora server (via extra_params or coolwsd.xml)
2. Open any document in Nextcloud Office
3. Enable the screen reader / accessibility checkbox in the UI (Help → Accessibility)
4. Close and reopen the document
5. Observe: the checkbox is unchecked again

Expected behavior

The accessibility preference is saved per user and restored on next session.

Actual behavior

The setting resets on every new session. Investigation of Nextcloud logs (with loglevel=1) reveals:

"method":"GET","url":"/apps/richdocuments/wopi/settings?access_token=...&fileId=-1&type=userconfig"

Collabora sends only GET requests to /wopi/settings?type=userconfig — it reads user config, but there is no corresponding POST from Collabora to save the UseATSupport preference back to the server. There is also no POST handler for user settings in richdocuments for this type.

Additionally, because Collabora runs in an iFrame from the same origin as Nextcloud in AIO, modern browsers restrict cross-origin localStorage access, so the browser-side storage of this preference is also unreliable and does not survive across sessions.

Root cause analysis

There is a fundamental architectural gap:

• accessibility.enable=true in coolwsd.xml enables the feature server-wide ✓
• The user must then individually activate it via the UI checkbox
• Collabora stores this checkbox state in the iFrame's localStorage only — there is no WOPI write-back for UseATSupport preference
• localStorage in a cross-origin iFrame context is blocked or cleared by browser privacy protections (Firefox ETP, Safari ITP, Chrome Privacy Sandbox)
• Result: the setting never survives a new document session

Proposed solution

One or more of the following should be implemented:

1. Server-side persistence via WOPI: Collabora should POST the UseATSupport (and other per-user preferences) to /wopi/settings?type=userconfig, and richdocuments should implement a POST handler that stores these preferences per user in Nextcloud's user preferences table (oc_preferences)

2. Admin-enforced default: An admin-level coolwsd.xml option such as accessibility.force_enable=true that activates screen reader mode for all sessions without requiring per-user opt-in

3. Same-origin iFrame: If Collabora were served from the same origin as Nextcloud (as is already the case in AIO via the built-in proxy), localStorage should in principle work — but the version mismatch warnings (/browser/dist/ instead of /browser/<hash>/) suggest the JS loading pipeline has issues that may also affect storage reliability

Additional context

Related log entries from Collabora container:

WRN  Client - server version mismatch, disabling browser cache. Expected: 0de01f3f02; Actual URI path with version hash: /browser/dist/fetch-settings-config
ERR  Invalid socket while sending wopi settings config from wopiHost[http://nextcloud-aio-apache:23973/apps/richdocuments/wopi/settings?access_token=...&fileId=-1&type=userconfig]

Start by tracing the /apps/richdocuments/wopi/settings?type=userconfig endpoint and checking how existing settings requests are handled. Investigate the UseATSupport preference and the reported localStorage behavior; done should mean the per-user accessibility setting is saved and restored in a new document session.