Another responder asked whether I had run “sudo apt autoremove” – yes, and to no effect.
But I managed to find a way to get past the original problem of having insufficient space in /boot to support system updates.
I did a work-around as follows. The kernel-image files themselves are used only at boot time: the image is loaded into RAM and executed. While it is running, the file itself will no longer be used, until the next boot. So it should be safe to move one of the images temporarily, perform the update, and restore the image to /boot. I inspected config.txt to see if a named image file was being invoked at boot; the kernel-image description was commented out. That means the system uses the default “kernel.img” at boot. I moved “kernel7.img” to /tmp, which provided enough space in /boot to allow updates to be done. After successful update, I returned “kernel7.img” to /boot. No problems since.
A longer-term solution would be to take the SD card out, put it into a USB reader attached to another system, and use gparted to enlarge the /boot partition. (I would have to first reduce the size of the other partition [root], and then assign the freed-up space to the /boot partition.)
Seems rather drastic just to do a simple maintenance task of removing defunct kernel images.
I also found in /lib/modules some evidence of six kernel images having been on the machine at one point or other. Makes me wonder if rpi-update is automagically doing some of the kernel-image maintenance for me – like keeping just the last two kernel images in /boot. That would, of course, be useful; but a little documentation to that effect would go a long way. And it still doesn’t solve the problem of having the distro set up a /boot partition that soon ends up being too small to accommodate ordinary maintenance.
Thanks to all for their assistance.