Feature Request: Allow collection admins (not just superusers) to choose and change the PID provider

Overview of the Feature Request
Allow collection admins (not just superusers) to choose and change the PID provider (e.g., DOI vs PermaLink) for their own collections. This lets institutions set provider policy per collection (department/group/project) without involving a superuser or restructuring the hierarchy.

What kind of user is the feature intended for?
Collection Admins / Stewards (with benefits to Curators and Depositors via clearer defaults per collection).

What inspired the request?
Common governance patterns:

Collections that act as catalogs for datasets that already have an external DOI should use PermaLink.

Collections that host and publish data should use DOI.
Today, enforcing these policies requires superuser intervention or awkward workarounds.

What existing behavior do you want changed?
Currently, while multiple PID providers can be configured, the effective control over which provider a collection uses is tied to superuser-only configuration or indirect methods. Collection admins cannot directly set or switch the PID provider for their collection.

Any brand new behavior do you want to add to Dataverse?

New granular permission at collection scope (name TBD, e.g., ManageCollectionPidProvider) that allows the collection admin to select among the already-configured providers available to the installation.

UI: In Collection Settings, add a “PID Provider” selector (restricted to users with the new permission).

API: Endpoint/option to set the collection’s PID provider with proper auditing.

Audit & Safety: Log who changed the collection’s provider, when, and from→to. Optionally restrict to a curated subset of providers per collection if desired by installations.

Any open or closed issues related to this feature request?

Related precedent: recent permission-splitting work (e.g., linking split into its own permission, #11691).

Start by reviewing the existing collection settings and PID-provider configuration, then use the permission-splitting precedent in issue #11691 to understand the expected scope. Define the permission, collection-settings selector, API option, and audit requirements so collection admins can select configured providers and provider changes record who changed what and when.