Make advanced attachment element visibility configurable (checksum admin-only by default)

[bram-atmire]

References

Fixes #5822

Description

Makes the visibility of advanced attachment elements (such as the bitstream checksum) configurable on the item page, and defaults the checksum to admin-only so it is no longer shown to anonymous and regular users.

Instructions for Reviewers

This only affects the advanced attachment rendering used on the item page when layout.showDownloadLinkAsAttachment: true (the ds-bitstream-attachment cards), which is the only place the checksum is rendered.

List of changes in this PR:

• Added an optional visibility property to each layout.advancedAttachmentRendering.metadata element, with two values:
  • public (the default when omitted) - visible to everyone, including anonymous users
  • admin - visible only to site administrators (gated on FeatureID.AdministratorOf)
  • To hide an element from everyone entirely, remove it from the metadata list (existing behavior).
• BitstreamAttachmentComponent now filters the configured elements by the current user's admin status before rendering (visibleMetadataConfig$).
• Set the default checksum element to visibility: admin in default-app-config.ts and config.example.yml (and the test environment), so out of the box the checksum is admin-only.
• Added unit tests covering admin-visible, admin-hidden, and always-public elements.

How to test:

1. Set layout.showDownloadLinkAsAttachment: true in your config.*.yml.
2. Open an item with a file as an anonymous user: the Checksum line is no longer shown.
3. Log in as an administrator and reload: the Checksum line appears.
4. Optionally change the checksum element's visibility to public (visible to all) or remove it (hidden from all) to confirm the three states.

Checklist

• My PR is created against the main branch of code.
• My PR is small in size.
• My PR passes lint validation.
• My PR passes all tests and includes new/updated Unit Tests.
• My PR includes details on how to test it.
• If my PR includes new libraries/dependencies: n/a.
• If my PR modifies REST API endpoints: n/a.
• If my PR includes new configurations, I've provided basic technical documentation in the PR itself (and in config.example.yml).
• If my PR fixes an issue ticket, I've linked them together.