Add support for Armadillo as a DataSHIELD backend

[villegar]

Summary

{dsROCrate} currently supports auditing DataSHIELD environments through Opal connections.

As Armadillo is increasingly being adopted as a DataSHIELD backend, it would be valuable for {dsROCrate} to support auditing Armadillo-based deployments directly.

This would allow the auditing framework to operate consistently across both major DataSHIELD backend implementations.

---

Motivation

The current auditing workflow assumes an Opal backend and relies on Opal-specific connection objects and APIs.

However, many DataSHIELD deployments are now using Armadillo as their backend platform. Supporting Armadillo would:

• broaden the applicability of {dsROCrate}
• enable auditing of modern DataSHIELD deployments
• provide a consistent auditing experience across backend implementations
• reduce backend-specific limitations for users adopting Armadillo

---

Proposed enhancement

Extend all audit components to support Armadillo connection objects.

This could be implemented through S3 method dispatch, allowing backend-specific audit logic whilst maintaining a common user-facing API.

For example:

safe_project.opal <- function(x, ...) {
  ...
}

safe_project.ArmadilloCredentials <- function(x, ...) {
  ...
}

The same pattern could then be applied across the auditing suite.

Potential methods include:

safe_project.ArmadilloCredentials()
safe_data.ArmadilloCredentials()
safe_people.ArmadilloCredentials()
safe_settings.ArmadilloCredentials()
safe_outputs.ArmadilloCredentials()

and any other backend-specific audit entry points.

---

Suggested scope

The implementation should aim to provide feature parity between supported Opal and Armadillo audits wherever feasible.

This would include:

• backend connection validation
• permission validation
• project-level metadata auditing
• data resource auditing
• user and permission auditing
• configuration auditing
• output disclosure control auditing

Where backend capabilities differ, methods should return informative messages explaining any unsupported checks.

---

Implementation notes

The proposed backend validation framework discussed in other issues would provide a natural foundation for Armadillo support by allowing:

• backend-specific connection validation
• backend-specific permission checks
• backend-specific capability checks

without introducing conditional logic throughout the auditing codebase.

---

Expected benefits

• support for both major DataSHIELD backends
• improved interoperability across deployments
• cleaner backend abstraction through S3 dispatch
• future-proofing as DataSHIELD infrastructure evolves
• broader adoption of {dsROCrate} across the DataSHIELD ecosystem