feat(files_sharing): unified sharing sidebar and dialog

[skjnldsv]

Replaces the share editor in the files sidebar with the unified sharing UI: a single flat list of shares, and the Vue 3 sharing dialog from @nextcloud/sharing for creating and editing them.

What changed

• Sidebar: one flat list ordered by permission, instead of the Internal/External sections. A share with several recipients renders as an expandable group with stacked avatars; every row shows its permission, and each recipient shows its own. Destructive actions live in the overflow menu.
• Dialog: reached through an OCA.Sharing bridge — the Vue 3 entry point registers it, the (still Vue 2) sidebar calls it. Once files_sharing is Vue 3 the bridge can go and the library be imported directly.
• Off by default: the whole thing stays behind sharing.unified_api_enable, which is off and now documented in the config sample. Turning it on is left to a follow-up.
• Bumps @nextcloud/sharing to 1.0.0-beta.2.
• Raises the unified sharing API's rate limits, which were set low enough that the dialog tripped them on its own.

Known gap

Legacy shares (oc_share) do not appear in the new list until a ISharingLegacyBackend is registered, which is backend work outside this PR. That is one of the reasons the feature stays off by default here; the frontend needs no change when the backend lands.

Testing

• npx vitest run apps/files_sharing — 104 unit tests, including the sidebar refresh and the delete/remove guards.
• NOCOVERAGE=0 ./autotest.sh sqlite apps/sharing/tests/CapabilitiesTest.php — pins the API to off by default.
• npx playwright test --project=sharing — 34 new end-to-end tests: opening the sidebar, listing and grouping, the row actions, creating and editing shares (including declined confirmations and editing a link share), plus whole journeys such as sharing with a group and then granting one person more than the group. Which sidebar the tab renders is instance-wide state, so all sharing specs now run in one serial project; the share editor specs turn the API off for their worker.

These caught a regression in this branch: the share detail listeners had been camel-cased, which Vue 2 does not match against the hyphenated events the entries emit, so the previous share editor stopped opening.

Notes for the reviewer

• Recipients cannot list the shares addressed to them through the unified API yet, so the tests assert what the share owner sees.
• The share-level permission select rebuilds its options whenever the share re-syncs, which detaches its open dropdown. A click that lands while that happens hits whatever is underneath — in one test run it silently toggled "Note to recipients". Worth a look, separately from this PR.
• The API's write endpoints allowed one call per one to five seconds, which the dialog exceeds by itself, so they are now sized per minute from the flows that use them. The per-recipient permission endpoint had no limit at all and got one. The end-to-end tests run against the real limiter rather than switching it off.

AI disclosure

This pull request was written with AI assistance (Claude Code); every commit carries an Assisted-by trailer. The code was reviewed by me before submission.

[provokateurin]

#63565

[skjnldsv]

this is more than a killswitch :)

[skjnldsv]

Also sad to see new vue components not directly written in <script setup lang="ts"> meaning we will have to refactor all of them again to enable vapor mode with Vue 3.

Right, I was thinking of vue2, but I forgot the last versions were supporting a nice setup approach, let me adjust! 👍

[skjnldsv]

I am not sure I like that this puts part of files sharing into non-legacy bundle.

I think, until we rewrite and drop the legacy part of the sharing sidebar, I don't wanna touch the clean sharing app :)

[provokateurin]

I don't wanna touch the clean sharing app

I think it's also good to not add this code that is files-specific to an app that is not files-specific.

Done