Bug: fsck and repack don't agree when a worktree index extension is "broken"

I came into a situation where a worktree index contains an invalid object ID in an extension. This causes git gc to abort half-way:

$ git gc Enumerating objects: 6, done. Counting objects: 100% (6/6), done. fatal: unable to read d3e1a3edd7d7851bbf811064090e03475d62fd44 fatal: failed to run repack

However, fsck does not find any problem:

$ git fsck Checking object directories: 100% (256/256), done.

The problem is an invalid object ID that occurs in a worktree index. If I copy the index to the main worktree, fsck does find the culprit:

$ cp .git/worktrees/wt/index .git/index $ git fsck Checking object directories: 100% (256/256), done. error: d3e1a3edd7d7851bbf811064090e03475d62fd44: invalid sha1 pointer in resolve-undo error: 4b40bf1072d6dfeebc09b11ee4d4f22ca2ce3109: invalid sha1 pointer in resolve-undo error: 5a494fd3a2182795e0723300ab1ac75c0797be5b: invalid sha1 pointer in resolve-undo

and git gc fails in the same way as before (of course).

I see three problems here:

- git fsck should detect the problem (if it really is one) in the
worktree index. It seems that it is just an index extension that is
affected. Perhaps it should be just a warning, not an error.

- If the objects mentioned in the index extension are precious, they
should not have been garbage-collected in earlier rounds of git gc
(which I certainly did at some point).

- I can't git gc the repository now, which is particularly annoying when
auto-gc is attempted after almost every git command. Of course, I know
how to get out of the situation, but it took some time to identify the
worktree index as the culprit. Not something that a beginner would be
able to do easily.

The repository I use for the above commands is attached. I hope vger doesn't strip it away.

-- Hannes