You didn't actually rename the files. Well, you did, but you didn't. Hang on: this can get confusing.
Git doesn't really work with files, not quite the way your computer does anyway. Git works with commits, and git push sends commits. GitHub therefore has no files on it; it just has commits.
Each commit does, however, contain a snapshot of all of your files, in a Git-ified format. These snapshots are read-only and compressed, and only Git itself can actually use them. To make them useful on your computer, your Git extracts any given commit to a work area.
Git complicates this a bit more: on your computer, Git first extracts the commit to Git's index. The index is actually a data file. It contains file names, but not in the form that your computer uses. For instance, a file named dir/sub/file.ext is literally just stored as dir/sub/file.ext in the index. Your computer demands that Git create a folder / directory named dir, then, inside that, create one named sub, then, inside that, create file.ext, so that there is a file named file.ext in a folder named sub in a folder named dir. (You might refer to this as dir\sub\file.ext, even.) But in the index, it's just a file whose name is dir/sub/file.ext.
File names in the index are case sensitive, and use forward slashes (always, even on Windows).
File names on your computer, having been stored into folders, are—at least on your computer; some differ—not case sensitive. That is, once dir\sub\file.ext exists, use of DIR\suB\fIlE.ExT accesses that same file. So it doesn't matter if you change the case of these on-disk files, because to your computer, file.ext, File.ext, and FILE.EXT are all the same file.
Your Git knows about this, and therefore can leave the old-case names in place in the index, even though you used whatever method you use on your computer to make them different.
If you use git mv, you can get Git to update the index copy of the file's name (while also updating the file's name in the file system). This may require a relatively modern Git; some older Git versions are less capable here.
For instance, on my Mac (which uses forward slashes, but also defaults to case-insensitive file system):
sh-3.2$ ls
File.Ext README.md
sh-3.2$ mv File.Ext file.ext
sh-3.2$ ls
README.md file.ext
sh-3.2$ git status
On branch master
nothing to commit, working tree clean
Note the lack of a rename. But now:
sh-3.2$ git mv File.Ext file.ext
sh-3.2$ git status
On branch master
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
renamed: File.Ext -> file.ext
(The Git on my Mac for testing here is a bit out of date, 2.20.1, but that's clearly late enough to make git mv work right.)
When you make a new commit, Git uses whatever is in the index, not what is in the work-tree. If the files in the index have the old-case names, the new commit will also have the old-case names.
It's not always easy to see what's in the index—git status shortens the output on purpose, by showing you what's different rather than what is there—and if you do this in a big project it will print out too much data, but, to see what's in the index, in its relatively raw form, use git ls-files --stage:
sh-3.2$ git ls-files --stage
100644 5f6a92a7cb8dec274ebbd7a471ba4101766336ab 0 README.md
100644 d2b181532c33ab30ff5396341da30a7ef162a1d6 0 file.ext
The leftmost field is the mode of the file, the next field is a blob hash,1 the third field—which will always be zero unless you're in the middle of a conflicted merge—is the "staging slot" number, and the last field is the file's name, complete with forward slashes (but neither of these have any slashes in them so this doesn't really show it, plus MacOS uses forward slash anyway).
So:
Now, the files exist on Github with the old capitalization ...
In fact, no files exist on GitHub at all. The code that lets you browse your GitHub repository looks at the commits and uses that to figure out what the file names would be. This stuff can be case sensitive, as it's not using actual files on your computer. In general, you'll see what Git saved from the index here.
What you'll see therefore depends on how you look: if you look in the work-tree (work area on your computer), your computer can do case-folding, causing interesting lies.2 If you look at the index, you'll see Git's truth as extracted from a commit. If you use GitHub's web browswer, you'll see truth filtered through your browser (which might potentially hide some things).
1The blob hash is determined by the file's content: Git doesn't store the actual file data directly in the index, but rather creates or re-uses one of its internal blob objects to hold the file's content. In this way, any time you commit the same content you have in any other file held in any other commit, Git can just re-use the existing frozen-format internal-only file. What's in the index, and therefore goes into each future commit, is the mode, path-name, and blob hash.
2On the Mac, file names are stored in NFD, which can interfere with the use of a file named schön or agréable that was first created on Linux, which just stores raw UTF-8 bytes however you write them. See this Super User post for details.
