Ensure HTTP status 404 is returned on Locking API

For a Git LFS client that has locking support (v2.0+), where an SSH remote is used the server will return a status 401 instead of a 404. The client will report as an "Authorization error" as below:

Lock failed: Authorization error: https://bitbucket.example.com/scm/myproject/lfstest.git/info/lfs/locks
Check that you have proper access to the repository

This occurs because the JWT auth token that is generated by GitLfsAuthenticateScmRequest has a query string hash (QSH) as is required by Atlassian JWT. This query string hash is for the Batch API (/info/lfs/objects/batch), where the LFS client (since Locking was introduced) will use this auth token on the Locking API (/info/lfs/locks/verify). The JWT Auth Filter then sees the QSH and URL do not match, and fail the request with a 401.

A status 404 is strongly preferred as the client will warn for a 401, and if a 404 is returned the .git/config will be updated to indicate the server does not support locking, so no further requests will be made to the locking API.