`/check` API endpoint returns nonexistent or inaccessible project IDs

[Phylogeny]

Please confirm the following.

• I checked the existing issues for duplicate problems
• I have tried resolving the issue using the support portal

Describe the bug

The API documentation for /check states that calling project/{id|slug}/check will return 404 if no project were found with the passed project ID or project slug, and that the project ID will be returned if such a project is found. However, when slugs are passed that don't correspond to any accessible project, IDs are often returned that also don't correspond to any accessible project. This is confirmed by 404 responses from /project/{id} with the retuned ID, and 404 pages that state "Project not found" from https://modrinth.com/mod/{slug} with the passed slug.

Steps to reproduce

Here is an example using the either nonexistent or inaccessible project randomtest:

curl -H "Accept: application/json" -H "User-Agent: project-check-test/1.0" https://api.modrinth.com/v2/project/randomtest/check
Returns {"id":"51n8OL83"}

curl -H "Accept: application/json" -H "User-Agent: project-check-test/1.0" https://api.modrinth.com/v2/project/51n8OL83/check
Returns {"id":"51n8OL83"}

curl -H "Accept: application/json" -H "User-Agent: project-check-test/1.0" https://api.modrinth.com/v2/project/51n8OL83
Returns 404

curl -H "Accept: application/json" -H "User-Agent: project-check-test/1.0" https://api.modrinth.com/v2/project/randomtest
Returns 404

https://modrinth.com/mod/randomtest
Returns a page with 404 Project not found

While a project with the project slug immersiveengineeringdoes exist, Here is an example using the either nonexistent or inaccessible project immersive-engineering:

curl -H "Accept: application/json" -H "User-Agent: project-check-test/1.0" https://api.modrinth.com/v2/project/immersive-engineering/check
Returns {"id":"MFUEfk14"}

curl -H "Accept: application/json" -H "User-Agent: project-check-test/1.0" https://api.modrinth.com/v2/project/MFUEfk14/check
Returns {"id":"MFUEfk14"}

curl -H "Accept: application/json" -H "User-Agent: project-check-test/1.0" https://api.modrinth.com/v2/project/MFUEfk14
Returns 404

curl -H "Accept: application/json" -H "User-Agent: project-check-test/1.0" https://api.modrinth.com/v2/project/immersive-engineering
Returns 404

https://modrinth.com/mod/immersive-engineering
Returns a page with 404 Project not found

Expected behavior

The last three returns for the randomtest and immersive-engineering examples above are correct, but the first two returns should be as follows:

For the randomtest example:

curl -H "Accept: application/json" -H "User-Agent: project-check-test/1.0" https://api.modrinth.com/v2/project/randomtest/check
Should return 404

curl -H "Accept: application/json" -H "User-Agent: project-check-test/1.0" https://api.modrinth.com/v2/project/51n8OL83/check
Should return 404

For the immersive-engineering example:

curl -H "Accept: application/json" -H "User-Agent: project-check-test/1.0" https://api.modrinth.com/v2/project/immersive-engineering/check
Should return 404

curl -H "Accept: application/json" -H "User-Agent: project-check-test/1.0" https://api.modrinth.com/v2/project/MFUEfk14/check
Should return 404

Additional context

This means that a 404 response from /check cannot be relied on to mean that a project with a passed slug can't be found, and that /project/{id} must always be called on a returned ID to check if it actually can or can't be found.

[Phylogeny]

Thinking more about this, it does make sense that /check returns the project IDs of private projects, since new projects can't be created with any used slug. So the fact that the scope of /get is public projects and the scope of /check is all projects is useful. But this does mean that the documentation is misleading. Currently, /get is titled Get a project, /check is titled Check project slug/ID validity, and both are documented as:

responses(
    (status = 200, description = "Expected response to a valid request"),
    (
        status = 404,
        description = "The requested item(s) were not found or no authorization to access the requested item(s)"
    )
)

At the very least, /get should be titled Get a public project, but ideally there should also be specific descriptions of each endpoint, rather than a generic title and return description. For example, /get could be:

responses(
    (status = 200, description = "Expected response to a valid request of a publicly accessible project"),
    (
        status = 404,
        description = "The requested project was not found or is not publicly accessible"
    )
)

And /check could be:

responses(
    (status = 200, description = "Expected response to a valid request of a public or private project"),
    (
        status = 404,
        description = "The requested project was not found"
    )
)