There are good answers that propose files and entries. (Go read them if you don't understand why those words fit, and remember that in POSIX "file" includes all types of inode (including directory), not just regular files). Directory entries (filenames) are references to files / inodes.
A file can have multiple names in different directories (link count > 1). The actual file data/inode isn't stored in the directory containing a filename for it.
But sane humans have no problem saying things like "read a file that's in some directory". It would be needlessly pedantic to bother always making the distinction between a file (inode + data) and the filename(s) / directory entries that refer to it.
Also note that directory entries in modern filesystems often also store a "type" field so programs like find don't need to stat(2) each file to check predicates like find -type f (regular file) vs. symlink or something. Or to find entries that are directories themselves when recursing. See Checking if a dir. entry returned by readdir is a directory, link or file. dent->d_type isn't showing the type on Stack Overflow.
A "path" like foo/bar or /a/b/foo/bar is a string that ends with a filename, but can use directories to refer to a filename that's not in the current directory. foo is a simple path and also a filename. But foo/bar is the name of a file, and also a path. But you could argue semantics that it's not "a filename". A path or pathname is something you can pass to a system call like POSIX open(2) or chdir(2) or Win32 OpenFile()
Your choice of terminology (file vs. filename vs. directory entry) will probably depend on context and what you're doing. e.g. reading the contents or inode metadata involves the actual file.
But just matching a glob expression against the name doesn't involve the file at all, just the filename / dir entry.
Directory entry is most appropriate when actually looping on a function like readdir(3), or for example "use ln to create a new directory entry referring to this file". When dealing with hardlinks, the term "dir entry" is usefully distinct from file, moreso than "filename".
But "name" also works. e.g. "a file with 2 names".
More often, you'd write a shell script using variable names like c_files=( *.c ). Or fn (for filename) is also a good local-use variable name.
Using entries=( *.c ) would feel weird. "entries" only feels right when talking about the process of looping over them to get filenames, not for the resulting set of filenames that match some filter.