I figured out how to do this. I wrote a Python script that listens for the DBus signals that indicate suspending and locking the screen. When both signals occur within a short time of each other, the script assumes that this is a suspend event that triggered a screen lock event. It then waits for the signal indicating a resume. If the elapsed time since the suspend event is less than 5 minutes, it forces the screensaver to unlock without requiring a password. In addition, it only unlocks the screen if the lid was closed when the suspend signal was sent (thus presumably indicating a suspend that was triggered by the lid closing), so manually suspending from the menu will not trigger the script. This ensures that the screen will not unlock after being manually locked by the user.
You can find the script here: https://gist.github.com/DarwinAwardWinner/77e8acea2f14ed9ea66d7222d7ace500
I saved the script in ~/.local/bin/, made it executable, and set the script up to run in the background when I log in using the Startup Applications configuration program, as shown here:
I also used run-one-constantly from the run-one package to automatically restart the script if it ever crashes for any reason. With this script running, I get exactly the behavior I want: if I close the lid and then open it a minute later, the screen unlocks without me having to type my password. But if I leave the lid closed for more than 5 minutes, or if I suspend the laptop without closing the lid, then it requires a password when I open the lid. You can configure both the time limit and the lid requirement by editing the script (look around line 100).
In its current form, the script only works with the GNOME screensaver. However, it should not be terribly difficult to adapt it to KDE or other screen locking programs, as long as they provide the appropriate DBus signals and methods.
Important security note: I've done my best to handle all edge cases I can think of, but there's always the possibility that I failed to anticipate some way of triggering the unlock even after the time limit has expired. Therefore, don't use this script if if you have concerns about security, unless you take the time to audit it yourself.
