Bug for ADA: the 4 fields (Name, Email, Institution, Position) for guestbooks are editable for logged in users

What steps does it take to reproduce the issue?

• Create a a dataset with at least 1 restricted file and allow access request.
• Create the guestbook for this dataset and include any or all of the 4 authenticateduser details: Name, Email, Institution, Position in the guestbook.
• Set the guestbook to appear at request (also happens when they download but the gb at request is ADA's primary workflow).
• Login as a regular user that will be able to request access.
• Go to the dataset and click 'request access' for the file.
• The guestbook pops up.
• The 4 fields are editable. Add any values to the fields that you like.

When does this issue occur?
With every guestbook.

Which page(s) does it occurs on?
All datasets that have a guestbook.

What happens?
See description of steps.
Being able to add any value to these 4 fields means the requesting user can spoof who they are and requires extra verification by the people evaluating the access request.

To whom does it occur (all users, curators, superusers)?
All users who enter guestbook values. All access request managers who need to evaluate the guestbook entries.

What did you expect to happen?
I expected that for a logged in user, that the values for the 4 fields would be pulled from the authenticateduser table, and be non-editable (especially for email address, which should be verified by the requesting user).

As the person setting up the guestbook, I would like to be able to specify these field values need to be pulled from the authenticateduser table and that they can't be edited.

ADA would want this to be an installation-wide setting but more flexibility (dataverse level, dataset level) may be useful at some point, and/or for other Dataverse installations.

Which version of Dataverse are you using?
6.2

Any related open or closed issues to this bug report?
Not that I can find.

Start by reproducing the guestbook-at-request workflow described in the issue for a logged-in user, then trace how the four authenticated-user fields are populated and submitted. Review the existing guestbook and access-request handling to determine where editability is controlled. Done means those fields cannot be altered for logged-in users while the current guestbook workflow still works.