Clarify RegistryCI license-check API for REUSE/SPDX-compliant packages

## Context Related to #48137 and #140158, but narrower: this is not about accepting non-OSI packages, but about recognizing OSI-approved licensing evidence in REUSE/SPDX-compliant repositories. ## Problem The current check appears oriented toward a single root `LICENSE` file. That works for simple packages, but is imprecise for repositories where source code, docs, CI files, generated files, and vendored files may have different license expressions. In such repositories, a full-text root `LICENSE` file can be misleading: it may suggest that the whole repository is under one license. REUSE/SPDX expresses this more precisely through SPDX headers, `REUSE.toml` / `.reuse/dep5` metadata, and canonical texts under `LICENSES/`. A root `LICENSE` file may therefore deliberately be only a pointer to the machine-readable licensing information. ## Reference case and possible tooling I have published an early-development reference package: https://github.com/bslMS/ReuseLicensing.jl The package currently provides SPDX license-expression parsing and policy evaluation. It is itself REUSE-compliant and uses a pointer-style root LICENSE file with canonical license texts under LICENSES/. The next development step is file-level and repository-level policy evaluation, likely consuming `reuse lint --json` and/or REUSE-generated SPDX/SBOM data. A RegistryCI-facing API could be as simple as: ```julia has_general_registry_approved_source_license(path)::Bool ``` or for diagnostics: ```Julia evaluate_package(path; policy = GeneralRegistryPolicy()) ``` The intended policy would be narrow: verify that package-relevant Julia source files have an **OSI-approved SPDX license path**, while reporting non-source domains such as documentation, metadata, CI files, or media separately. ## Questions 1. Would General be open to treating REUSE/SPDX evidence as an alternative to the traditional single root LICENSE heuristic? 2. Should such a check be repository-wide, or restricted to package-relevant source domains such as `src/`, `ext/`, generated Julia files, and files included in the package tarball? 3. Would a pointer-style root LICENSE file be acceptable if the authoritative license information is REUSE-compliant and machine-verifiable? 4. Would `ReuseLicensing.jl` itself be a useful reference case, or should I adapt its layout before attempting registration? I would be happy to shape `ReuseLicensing.jl` so that it exposes a small, stable API for CLI suitable for RegistryCI, if there is interest in this direction. --- Disclosure: I used AI assistance to improve the clarity and structure of this issue text.