git fsck --full only checking directories

On the corruption issue

Yes, you are missing something. Namely, you didn't corrupt the file in a way the Git pays attention too. Object's stored on disk generally start with the object type, followed by space, followed by the size (using ASCII numbers), followed by a a NUL. The size states how big the object is, and that's all that Git ends up reading. So tacking data to the end like that won't actually corrupt the object. If you replaced the contents of the file with something else, then you'd see the issue.

For reference, the object format details are in the Git User's Manual:

Object storage format

All objects have a statically determined "type" which identifies the format of the object (i.e. how it is used, and how it can refer to other objects). There are currently four different object types: "blob", "tree", "commit", and "tag".

Regardless of object type, all objects share the following characteristics: they are all deflated with zlib, and have a header that not only specifies their type, but also provides size information about the data in the object. It’s worth noting that the SHA-1 hash that is used to name the object is the hash of the original data plus this header, so sha1sum file does not match the object name for file.

As a result, the general consistency of an object can always be tested independently of the contents or the type of the object: all objects can be validated by verifying that (a) their hashes match the content of the file and (b) the object successfully inflates to a stream of bytes that forms a sequence of <ascii type without space> + <space> + <ascii decimal size> + <byte\0> + <binary object data>.

The structured objects can further have their structure and connectivity to other objects verified. This is generally done with the git fsck program, which generates a full dependency graph of all objects, and verifies their internal consistency (in addition to just verifying their superficial consistency through the hash).

However, there is an interesting interaction that leads me to think that git fsck should be working harder and noticing when the file has garbage at the end. If you attempt to run git gc on that repo, you'll end up see an error like this:

:: git gc
Counting objects: 9, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (3/3), done.
error: garbage at end of loose object '45b983be36b73c0788dc9cbcb76cbb80fc7bb057'
fatal: loose object 45b983be36b73c0788dc9cbcb76cbb80fc7bb057 (stored in .git/objects/45/b983be36b73c0788dc9cbcb76cbb80fc7bb057) is corrupt
error: failed to run repack

It seems like if git gc can't actually run, then git fsck should be catching the issue.

On why you don't see "Checking objects"

This issue is actually really simple: there are no packed objects to check. Those live in .git/objects/pack. If you don't have any of those files, then you won't see the "Checking objects" bit.