git.revParse doesn't resolve abbreviated (short) commit oids

[zeke]

docs/13_git_interface.md says rev-parse resolves "a ref (branch, tag, short oid prefix) to its full SHA-1," but a short oid prefix throws NotARepositoryError-shaped GitErrors in practice (Could not find <prefix>.).

Repro against a real, tiny public repo (octocat/Hello-World), using @cloudflare/computer 0.1.1's createGitClient() inside a withWorkspace-wrapped Durable Object, no exec backend:

await ws.git.clone({ url: "https://github.com/octocat/Hello-World.git", ref: "master", depth: 200, singleBranch: true });

const log = await ws.git.log({ depth: 5 });
// log[2].oid === "553c2077f0edc3d5dc5d17262f6aa498e69d6f8e" ("first commit")

await ws.git.revParse({ ref: "553c207" }); // 7-char prefix of the oid above
// throws: GitError: git rev-parse failed: Could not find 553c207.

await ws.git.revParse({ ref: "553c2077f0edc3d5dc5d17262f6aa498e69d6f8e" }); // full oid
// resolves fine

Same failure through catFile/diff/fileAt-style calls that internally revParse a caller-supplied ref first -- any short oid a caller might reasonably pass (e.g. one echoed back from git log's own output, formatted the way real git log --oneline would) fails, while the full 40-char oid works.

Worked around it on our end by never truncating an oid we hand back from git.log results (full 40 chars, not the usual 7-char short form), so any oid a caller reuses as a ref elsewhere stays resolvable. Filing since the docs explicitly describe short-oid support as working today, and it'd be nice for downstream code to not have to work around it.

Found while building https://github.com/zeke/dial-a-repo (an open-source voice-agent demo that clones repos live to answer phone-call questions about git history) -- happy to share more repro details if useful.