cli: hash-object -t <non-blob> <file> reports "unknown oid type" in GIT_EXPERIMENTAL_SHA256 builds when -w is not given

從 cli/cmd/hash_object.c 第 133 行附近開始，並檢查 src/libgit2/repository.c:4242 中的 git_repository_oid_type。在 GIT_EXPERIMENTAL_SHA256=ON 建置中重現非 blob 的 hash-object 命令，然後驗證不帶 -w 的命令回報的驗證錯誤與非 SHA256 建置相同，而不是 "unknown oid type"。

Reproduction

In a GIT_EXPERIMENTAL_SHA256=ON build of the git2 cli binary:

$ echo hello > hello.txt
$ git2 hash-object -t commit hello.txt
git2: unknown oid type

Same command in a default (non-SHA256) build:

$ git2 hash-object -t commit hello.txt
git2: failed to parse bad commit object

The non-SHA256 message makes sense: the buffer isn't a valid commit. The
SHA256 message is confusing because the implementation ends-up short-circuiting on finding a hash algorithm.

Also reproduces with -t tag, -t tree, and any flag combination that ends up using a non-blob type. It does not reproduce for -t blob, because git_object_rawcontent_is_valid
short-circuits before reading oid_type for blobs. It also does not reproduce when -w is passed (a repo is opened, so oid_type gets the hash type from the repo).

Root cause

In cli/cmd/hash_object.c:

/* line 133 */
oid_type = git_repository_oid_type(repo);

When -w is not passed, repo is NULL (the cli_repository_open block above is gated on write_object). And
git_repository_oid_type(NULL) returns 0 (src/libgit2/repository.c:4242):

git_oid_t git_repository_oid_type(git_repository *repo)
{
    return repo ? repo->oid_type : 0;
}

0 isn't a valid git_oid_t discriminant. In the non-SHA256 build it
doesn't matter since hash_buf does GIT_UNUSED(oid_type) and calls the non-oid_type overload of
git_object_rawcontent_is_valid, which validates as SHA1 unconditionally. In the SHA256 build though, hash_buf passes the 0 down to git_object_rawcontent_is_valid -> git_object__from_raw -> git_oid_algorithm, which has no arm for 0 and errors with "unknown oid type".

So the behavior seems asymmetric by accident for which overload hash_buf selects. Refusing non-blob hash-objects without -w in SHA256 builds only is probably unintentional.