Symptom

Over an SSH remote, git lfs reports:

Remote "origin" does not support the Git LFS locking API.

and a subsequent git push hangs.

Root cause

Both symptoms trace to the same gap as #65: with no git-lfs-authenticate handoff, an SSH client cannot discover the HTTP LFS endpoint. It falls back to guessing an HTTPS URL derived from the SSH host, then:

1. POST /locks/verify against the guessed (nonexistent) endpoint fails → git-lfs prints ‘does not support the LFS locking API’.
2. The object transfer to the guessed/unreachable endpoint hangs (connect to a host/port that isn’t serving HTTP).

This was invisible because all existing interop coverage sets an explicit lfs.url and uses git lfs push --all <url> over HTTP (issue #58 scoped LFS to HTTP + PAT auth only; SSH was never considered).

Relationship to #65

#65 adds the git-lfs-authenticate mechanism. This issue tracks the observable locking defect and its verification: once discovery works, the locking API must be reachable and correct over the discovered endpoint, and the push must not hang.

Scope

• Verify Lfs.Locks endpoints (create/list/verify/unlock) resolve and behave correctly against the SSH-discovered LFS href.
• Confirm the git-lfs-authenticate href is the LFS root so /locks and /locks/verify resolve.
• Audit Locks.verify/2 against what git lfs sends at push time (the ref/cursor request body) and what it expects back (ours/theirs, optional next_cursor); fix any real mismatch found by reproduction (not speculative).

Acceptance criteria

• Interop: over an SSH-style remote with no explicit lfs.url, git lfs lock/locks/unlock round-trip and a git push completes without printing ‘does not support the LFS locking API’ and without hanging.
• Push-time lock verification (POST /locks/verify) returns 200 with correct ours/theirs.
• Regression test proves the hang is gone (bounded-timeout interop test).
• CHANGELOG updated; anvil requirement status passes.