Add comment-only permission for read-only shares via WOPI UserCanComment field

Is your feature request related to a problem? Please describe.

When sharing a document in read-only mode via Nextcloud, recipients cannot add comments inside the Collabora editor. This makes document review workflows impossible without granting full edit access — which is often undesirable. In Google Docs, "Commenter" is a distinct permission level between "Viewer" and "Editor", and the absence of an equivalent in Nextcloud Office is a significant gap for teams migrating from Google Workspace.

Describe the solution you'd like

Collabora Online already supports comment-only mode for read-only documents, implemented in CollaboraOnline/online@fe4c1b6. This restricts users in read-only mode from modifying or deleting other users' comments, while still allowing them to add their own.

Looking at the current codebase, the implementation would follow the same pattern already used for the download share attribute in PermissionManager.php and TokenManager.php:

1. TokenManager.php — read a comments attribute from $share->getAttributes() when generating the WOPI token (mirroring how the download attribute is already handled), and store it on the Wopi entity
2. Wopi.php — add a canComment boolean property to the entity
3. WopiController.php — add a UserCanComment field to the CheckFileInfo response, set to true when UserCanWrite is false but the share has comment permissions
4. Sharing UI — expose a "Can comment" toggle in the sharing dialog that sets the share attribute, alongside the existing "Can edit" and "Can share" options

Describe alternatives you've considered

• Granting full Edit access to reviewers — works but undesirable as it allows unintended document modifications
• Using Nextcloud's file-level comments (in the sidebar) — available to read-only users but separate from the document itself, not the same experience as inline document comments

Additional context

The Collabora-side implementation already exists (see commit above). The missing piece is entirely on the Nextcloud/WOPI side. The good news is the codebase already has all the right patterns in place — IAttributes for fine-grained share permissions (already used for download), and canwrite as a model for how edit permissions flow from token generation through to the WOPI response. A canComment permission would follow the exact same path.

Start with the existing download handling in TokenManager.php and PermissionManager.php, then trace the Wopi.php entity into WopiController.php's CheckFileInfo response. Review the sharing dialog code to find where Can edit and Can share are exposed. Done means the comments share attribute flows through the token and WOPI response, and the UI can configure it without granting edit access.