Error message from Dataverse API endpoints for destroying datasets and sending metadata to a PID provider can be misleading

What steps does it take to reproduce the issue?

• When does this issue occur?
  When using the the API endpoints destroying datasets and for sending metadata to a PID provider like DataCite, and including a persistentId that doesn't exist in the Dataverse installation, such as:

  • curl -H "X-Dataverse-key: $API_TOKEN" -X POST "https://$SERVER/api/datasets/:persistentId/destroy/?persistentId=doi:10.7910/DVN/12345"
  • curl -H "X-Dataverse-key: $API_TOKEN" -X POST "https://$SERVER/api/datasets/:persistentId/modifyRegistrationMetadata/?persistentId=doi:10.7910/DVN/12345"

• Which page(s) does it occurs on?
  The confusion can occur where a user sees what the endpoints return, like in the terminal or IDE they used to call the API endpoint

• What happens?
  When using the the API endpoints and providing a persistentId for the query parameter, if the PID doesn't exist in the Dataverse installation, the endpoints return an error message that reads "When accessing a dataset based on Persistent ID, a persistentId query parameter must be present," even when the API user included the persistentId query parameter.

  This can cause confusion about the cause of the error and what the user should do next, since the problem isn't that the persistentId query parameter isn't present, but that the persistent ID doesn't exist in the Dataverse installation.

• To whom does it occur (all users, curators, superusers)?
  Superusers

• What did you expect to happen?
  The error message would let the user know what caused the error so that they can at least infer how to fix it.

  When the persistentId is something like doi:12345, the endpoint returns "Bad dataset ID number: doi:12345," which I think is a less confusing error message. Could that message be used?

  Why does the endpoint return a "bad dataset ID number" message when the persistentId is doi:12345 and a "persistentId query parameter must be present" message when the persistentId is doi:10.7910/DVN/12345? Both persistentIds do not exist. Did we tell Dataverse to check only the format of the given persistentId?

Which version of Dataverse are you using?
v6.9

Any related open or closed issues to this bug report?
I couldn't find any directly related to this API endpoint's error message, but there may be other endpoints that might cause this confusion. I first saw this with the modifyRegistrationMetadata endpoint, then with the destroy endpoint later.

Screenshots:

Start by reproducing the destroy and modifyRegistrationMetadata requests from the issue with a nonexistent persistentId, then trace the API handlers that produce the two different error messages. Done means both endpoints clearly report that the persistent ID does not exist, rather than claiming the persistentId parameter is missing.