Unconditionally include API token for public files when forwarding to "explore" tools

Issue/Surprise:
When sending the user to an external tool of type "explore" for a file, the user's API token is omitted if the file is part of a fully public dataset. The API token is only included when the file is either part of a draft or resides in a restricted dataset/dataverse (see below code snippet). This happens despite the tool declaring the API token to be part of the tool invokation.

Expected Behavior:
If the external tool declaration contains the {apiToken} reserved word as part of its parameter specification, it could be expected to always receive a valid API token as part of the request.

Request Context:
In an ongoing project we are exploring the technical possibilities of providing partial access (aka excerpt generation) to protected (copyrighted) text material in accordance with the (local) legal framework. Since Dataverse is already used as data repository at our university and the external tools API offers an excellent method of integrating additional/outsourced functionality, we opted for it as basis for our project. As part of the intended workflow a public dataset (e.g. the unrestricted publication or "cleaned" research data) would include a manifest file (JSON, JSON-LD) that links to the protected associated resource for which an excerpt could be created (the tool has access to the restricted section due to a separate API token of a read-only user). We would prefer to not duplicate user authentication/management, so the tool uses the user info API of the dataverse calling it to track each user's quota on restricted files. This subsequently breaks if the dataverse decides to not include the API token when invoking the external tool.

Associated Code:
Section resppnsible for current behavior is located in method explore of edu.harvard.iq.dataverse.FileDownloadServiceBean:

ApiToken apiToken = null;
User user = session.getUser();
DatasetVersion version = fmd.getDatasetVersion();
if (version.isDraft() || (fmd.getDataFile().isRestricted())) {
    if (user instanceof AuthenticatedUser) {
        AuthenticatedUser authenticatedUser = (AuthenticatedUser) user;
        apiToken = authService.findApiTokenByUser(authenticatedUser);
        if (apiToken == null) {
            //No un-expired token
            apiToken = authService.generateApiTokenForUser(authenticatedUser);
        }
    } else if (user instanceof PrivateUrlUser) {
        PrivateUrlUser privateUrlUser = (PrivateUrlUser) user;
        PrivateUrl privateUrl = privateUrlService.getPrivateUrlFromDatasetId(privateUrlUser.getDatasetId());
        apiToken = new ApiToken();
        apiToken.setTokenString(privateUrl.getToken());
    }
}

I searched existing issues for a rationale of this case differentiation, but could not find nothing specific. So my main question is whether removing the check and unconditionally include API tokens when the external tools specifies them as parameter would break existing contracts or violate security considerations?

Start in edu.harvard.iq.dataverse.FileDownloadServiceBean, method explore, and trace how the external tool parameter specification controls the request. Review the existing token conditions and related security or contract expectations; done means the behavior for public files is explicitly defined and covered by the relevant tests.