Show .pad files in the Nextcloud Files type filter

[Jaggob]

Open item from ToDo.md: surface .pad files as a dedicated entry in the Files-app type filter (the dropdown that lets users filter by Documents / Spreadsheets / etc.).

Why this is "blocked"

The Nextcloud Files-app type-filter is currently not exposed via a documented public extension point. Possible paths today:

• Patch the Vue file-list filter at runtime via JS — fragile, breaks across NC versions.
• Server-side mime-type registration — already done (application/x-etherpad-nextcloud), but does not by itself add a filter button.

We deliberately want to wait for a stable upstream extension point rather than DOM-patch the filter dropdown.

When to revisit

• When Nextcloud publishes a documented Files-filter extension API.
• Or when a stable mime-category registration mechanism exists that the type filter consumes automatically.

Track upstream Nextcloud release notes / Files-app changelogs for either signal.

Acceptance

• Implementation only proceeds via a documented extension point — no DOM patching of the Vue filter UI.
• .pad files appear as their own filter entry with the correct icon.
• Tested across the supported Nextcloud version range stated in appinfo/info.xml.

[Jaggob]

Plan for surfacing .pad in the Files type filter — experiment first, then choose.

Two candidate approaches; we'll validate empirically before committing, because the modern Vue Files app may resolve icons/filters differently than the legacy OC.MimeType path.

Option A — MIME alias (simplest, if it doesn't cost the icon): map application/x-etherpad-nextcloud → x-office/document in config/mimetypealiases.json (the RegisterMimeType repair step already owns that file). The "Documents" filter category matches x-office/document, so aliased pads would show up there — no DOM patching, uses the documented config-mimetype mechanism.

• Risk: the mimetype alias historically drives both the filter category and the file icon (getIconUrl() resolves the alias first), and there is only one alias value per mimetype — so this could replace the custom .pad icon with the generic document icon everywhere in the Files view, not just in the filter. Keeping the pad icon is a hard requirement.
• Test (on NC 33, then across 31–33): set the alias, regenerate the mimetype JS (occ maintenance:mimetype:update-js), and check live whether (a) pads appear under the Documents filter and (b) the custom icon survives in the file list. Ship Option A only if the icon survives.

Option B — dedicated filter entry (icon-safe fallback): register our own filter chip via registerFileListFilter() from @nextcloud/files (added in NC 30, available across 31–33) — custom matching on our mimetype plus our own icon, no DOM patching. This is the documented extension point this issue was waiting for, and it preserves the pad icon.

Implementation will be its own PR, separate from the MIME-registration cleanup (#108). Keeping blocked until the experiment confirms which option is viable on the supported range.

[Jaggob]

#130: The implementation to map “application/x-etherpad-nextcloud” as an alias for “x-office/document” works, but is not yet been merged because I don't really like the way to pretend that our pads are x-office files – more research needed if this could have broader implications