Thanks to you all and thanks to Andy at Canonical who gave some good pointers in another forum. I've poked around at this a bit, not just here, and I've learned a few things and come to suspect some others. Too much to put in a comment.
Strictly speaking, the question was answered correctly and promptly by user535733 in the second comment to my initial post and in fairness, if he'll put that in an answer, I'll be glad to accept it.
@user535733 - Note the above, please.
But the subject was expanded by waltinator in the first comment to include the possibility of creating a tool to do the job and by David into HOW apt-check works and WHY it won't do this without linux-generic installed.
The following is nowhere near complete, some of it is speculation (clearly labeled I hope), there might even be a few outright mistakes (imagine that) and I may come back and edit some more stuff in. Maybe somebody stumbling on this page will find some of this of interest. You may have to run the commands on your own system to see the output clearly in the correct format.
re apt-check & linux-generic:
Linux-generic seems to be a red herring. Mea culpa, I assumed it's lack was the problem. I now don't think apt-check can't do this AT ALL, even if linux-generic IS installed. It is a tricky question to test without installing 4.4.0-77. I'll test in the future, when I don't have to worry about a kernel that consistently breaks my xenial systems.
The problem is NOT that apt-check doesn't have access to the necessary data. You definitely do NOT need linux-generic installed to get metadata about potential kernel upgrades sufficient to show what's available and if it has security fixes.
I assume "apt-get update", a part of apt, gets the info (more on that below), but WHATEVER gets it:
it does NOT require linux-generic be installed to see potential kernel upgrades.
it does NOT require linux-generic be installed to determine which kernel version linux-generic currently depends on.
it does NOT require linux-generic to determine if a potential kernel upgrade has security fixes in it.
Furthermore, whatever gets this information to begin with, the information persists locally (presumably until you clear it). So even off line and without linux-generic installed, apt-check has access to the necessary information - it just doesn't use it, probably BY DESIGN. But it can be used in a script - I do not have linux-generic installed and here are 2 examples of a test that works on my system even offline:
$ apt-cache showpkg linux-image-4.4.0-75-generic | grep "$(lsb_release --codename --short)-security"
and the output:
4.4.0-75.96 (/var/lib/apt/lists/us.archive.ubuntu.com_ubuntu_dists_xenial-security_main_binary-amd64_Packages) (/var/lib/apt/lists/us.archive.ubuntu.com_ubuntu_dists_xenial-updates_main_binary-amd64_Packages)
So, 4.4.0-75 HAS security fixes.
$ apt-cache showpkg linux-image-4.4.0-77-generic | grep "$(lsb_release --codename --short)-security"
and the output (just a return of the prompt):
4.4.0-77 does NOT.
re apt-check & apt:
Apt-check, part of update-notifier-common (not update-notifier as stated above), may depend on apt for its info about packages, as David indicates, probably specifically on "apt-get update", even if apt does not depend on linux-generic for info on potential kernel upgrades. It is what I would expect and I don't see any alternative, but strangely, unless the devs have marked the dependencies wrong, apt is NOT a dependency for apt-check:
$ apt-rdepends update-notifier-common | grep apt
and the output:
Reading package lists... Done
Building dependency tree
Reading state information... Done
Depends: libapt-inst2.0 (>= 1.1~exp9)
Depends: libapt-pkg5.0 (>= 1.1~exp9)
Depends: libapt-pkg5.0 (>= 1.1~exp9)
So, in theory, you don't need apt to run apt-check - you could use it on a sytem managed with dpkg and dselect, although I fail to see how that could work. I certainly wouldn't give odds that it would until I actually tried it (and I may out of curiosity later) but that is the way the dependencies are marked. You'd think the devs would mark apt as a dependency for update-notifier-common if one of its commands REQUIRED apt to work, but it may be an oversight.
So, with respect to the original question, here is what I now suspect is true:
"Can apt-check . . . be made to treat potential kernel upgrades, the same way it does non-kernel upgrades, detecting them and distinguishing between those that incorporate security fixes, and those that don't . . . without having the meta-package linux-generic installed?"
No, and it probably can't WITH linux-generic either.
"And if apt-check can't do this, is there some other program that can?"
No, not out of the box, so to speak.
But, re creating something that can
As waltinator suggested apt-check could probably be re-written to do so if you have the knowledge and inclination. But, as David suggested, this function can probably be scripted with other tools and I can probably do that a lot easier than learning how to re-write apt-check.
As mentioned earlier you can get the name of the package containing the newest, shiniest kernel blessed by Canonical by applying some grep and cut magic to the output of:
apt-get install --simulate linux-generic
and you can classify it as having/not_having security fixes with something like
apt-cache showpkg linux-image-4.4.0-75-generic | grep "$(lsb_release --codename --short)-security"
as illustrated above.
Ideally, to script this, we need a complete version history of what linux-generic has depended on to avoid a false negative in a situation this:
You have version 100 installed.
Version 101 had security fixes but your computer wasn't turned on that week.
Version 102 does NOT have security fixes (relative to 101, but it does relative to 100 since it still has the ones that were made in 101).
It would be nice if I could curl a complete version history of linux-generic, and somehow find out which "pocket" of the repo the dependent kernels were published in. So far, I've only discovered how to do this for old versions that are still in the repo.
apt-cache madison linux-generic
is headed in the right direction but I think it only gets what IS in the repo, not what WAS in the repo, so I'm not sure the info it yields will be sufficient to prevent the false negative scenario detailed above. If in the example above, 101 was already gone from the repo, I don't think the info from "apt-cache madison linux-generic" would be sufficient.
And, oh yeah
One more thing I should point lest somebody get interested in this and spend a lot of time on it without knowing it:
I'm still poking at this because I got started and I'm stubborn. But while, by pure happenstance as far as I can tell, the kernel that has given me problems does NOT have security fixes, and therefore if I had a working script for this, it never would have broke my xenial systems, Andy tells me that 4.4.0-77 is a rare case and that the great majority of kernel upgrades that linux-generic depends on DO have security fixes. I suspect he was being figurative/hyperbolic when he said "99%", but even allowing for that, I suspect an apt-check like mechanism that applies to potential kernel upgrades isn't going to prevent an un-needed (security-wise) upgrade very often, and so will prevent un-needed kernel upgrades breaking apt or other crucial system components, even more rarely. It appears to be just random happenstance that it would have done so for me. BTW, 4.4.0-78 works fine for me. Andy was right - whatever it was about the 77 is fixed.