If you are tired of maintaining your old project just put a tar.gz of the last stable release up on your own site and let it die or be used. Or, at the very least, disable GitHub's issue tracker.
But some people (like you) will assume by default that it is supported. So be clear in your README that it ain't. I think we should start popularizing the term 'abandonware' here -- some code starts out as abandonware, but other code becomes so when the authors lose interest. We all know that using abandonware is 'riskier' to your project long-term than using supported open source, and many of us find ourselves depending on abandonware that used to be supported, and looking for alternatives. So it goes.
And especially for 'abandonware', I think it's actually much better to put it in a github repo than as a .tar.gz. One of the main uses for born-abandoned open source would be to look at the source code as an example and copy-paste from it, and a github repo makes those sorts of uses a lot easier in several ways than a .tar.gz.
This is about as incorrect a statement as one could make on the issue.
In any case, your definition is in stark conflict with historical usage. "Open source" was coined in 1998 when the majority of releases were as tarballs on ftp sites, and SourceForge hadn't even started. By your definition then, all of those self-labeled open source projects of 1998 didn't actually exist.
It's also ridiculous because it means that when I die, and there's no one else who wants to support it any more, then it somehow loses its "open source" status.
Make it clear in the README that you won't provide any further support and disable the issue tracker if you don't want people to contribute or ask for help.
I also don't understand why someone would expect continuous support without checking whether the project is in development or not.
Making it clear in the README that no maintenance is guaranteed and disabling the issue tracker should be enough to send the message to would be users. If the OP doesn't do that he is actively implying future maintenance.
Having an account on Twitter doesn't mean there's an obligation to respond to every tweet directed your way.
In dating web sites there's no obligation to reply to every "hi, I'm interested in you" message.
In fact, in no social site I know of has an obligation for future engagement.
Why is code different?
You also assume that "social" => "with the world." If I want to work on a project with friends in California and New Zealand, why not set it up as a public account on github? We're being social, just not social with you. Our obligations are towards each other, not some stranger on the internet.
Should I shut down the SF account?
Actually, I think what you imply is publishing source code in a public repository says that I have a social obligation to work at no cost.
Why can't I charge for my time?
Why can't I ignore people I don't like?
That seems rather ... needless. Surely it's better to assume that no one is obligated to respond to you than to cater to unrealistic and unreasonable hopes and promote this practice as being somehow necessarily.
I also doubt it will make a difference. People don't read READMEs in general, much less for details about support options.
Those are all things i am likely to want to do with code published open source but as unsupported 'abandonware', use it as an example to look at and copy and paste from, instead of just using the product as is as without looking at the source.
In fact, the one thing I'd be less likely to want to do with abandonware -- actually install and use it, instead of just consulting it as an example -- is the one thing you haven't actually made that much more difficult by publishing only as an archive.